To find missing information assets and systems in a security assessment, start with a business service and trace what people actually use to deliver it. Compare that working picture with the assessment, rather than assuming the existing technology inventory is complete.
A business may depend on a supplier portal, shared spreadsheet or specialist controller that is absent from the main register. The omission matters when it hides an important consequence, an owner or a dependency needed for protection and recovery.
This article addresses information and supporting systems. It is not a complete method for inventorying every physical asset. The outcome is a supported list of additions and corrections, with enough context to assess their importance.
Start with a service, not a software list
Choose a service the organisation needs to deliver, such as processing customer requests, scheduling field work or issuing test results. Ask the service owner to describe the steps and the information needed at each one.
Follow the work with the people who perform it. Include normal operation, an exception and a workaround. Ask what they use when the main system is unavailable or when a request cannot follow the ordinary process.
Record system names, information sets and third-party services in terms the users recognise. Keep aliases where the same system has a technical name and a familiar business name. Otherwise, apparent omissions may be naming differences and apparent duplicates may be separate services.
The UK NCSC's guidance on identifying critical assets connects organisational objectives with technical assets and their dependencies, including third-party services. Its cyber-security context supports this discovery approach; it does not establish that your inventory is complete.
Compare several views of the same work
Use the existing assessment, service documentation, procurement records and the relevant IT or operational-technology inventory as starting evidence. Obtain information through authorised owners rather than conducting unapproved scans or accessing other people's data.
Ask each owner what their record includes and excludes. A finance asset register may omit leased or low-cost services. An IT inventory may omit systems managed by a facilities supplier. A procurement list may include subscriptions no longer in use.
Reconcile the differences instead of simply combining lists. Determine whether the entry is current, what service uses it, who manages it and why it was absent from the assessment.
Avoid copying unnecessary sensitive contents into the inventory. Usually you need to describe the information and its purpose, not collect the customer records or credentials themselves.
Follow dependencies one step beyond the obvious
For each material system, ask what it requires to deliver its service and what depends on its output. Include hosting, identity, communications, external support and interfaces where relevant to the assessment boundary.
A dependency can be important even when your organisation does not own it. Record the relationship and responsible contact rather than pretending you control the supplier's entire environment.
Look for shared dependencies. Several apparently separate business systems may rely on one identity service or one supplier. That matters when considering simultaneous disruption or recovery sequencing.
Keep the level of detail proportionate. The service owner needs a usable picture of consequential relationships, not an unmaintainable catalogue of every technical component. Refer detailed architecture to the controlled technical record.
Worked example: a maintenance service
A fictional facilities business initially lists only its main job-management application. A walkthrough of urgent maintenance requests reveals the following additions.
| Discovery | Why it matters | Assessment correction |
|---|---|---|
| Supplier portal used to obtain specialist parts | Some urgent work cannot proceed without access or an alternative ordering route | Add the dependency and name the supplier relationship owner |
| Shared spreadsheet used for jobs received during outages | Changes and reconciliation affect which jobs are completed | Record its owner, use and integrity concerns |
| External identity service used by the main application | Staff access depends on a service outside the application itself | Link the systems and confirm the relevant support arrangement |
| Historic export still used for customer contact details | Staff may rely on outdated information during an incident | Verify the purpose, accuracy and approved retention decision |
The team does not label every discovery critical. It asks what would happen if the information were disclosed, changed incorrectly or unavailable, and records the reasoning before prioritising work.
Distinguish value from current protection
An important system may be well protected. A weakly protected system may support a low-consequence activity. Keep the consequence of compromise separate from the assessment of existing controls.
Consider confidentiality, integrity and availability separately. A public information service may contain little secret information while its accuracy or availability remains important. A single sensitivity label can hide that distinction if used without explanation.
Use the organisation's approved consequence criteria and document assumptions. If the consequence depends on an alternative service, establish whether that alternative is available and sufficiently capable before reducing the assessment.
Do not infer a precise impact level solely from purchase price or the number of users. Ask the service owner to explain the operational consequence and have the appropriate decision-maker review it.
Assign ownership and close the discovery loop
Each material addition needs someone able to maintain the record and coordinate decisions. The technical administrator may provide evidence while a business owner decides how important the service is.
Where ownership is unclear, escalate the gap rather than inserting a convenient name. An assigned person who lacks authority cannot resolve treatment or resource decisions.
Update the assessment and related records through their owners. Record exclusions and unresolved areas as well as additions, so the revised list does not imply a completeness you have not demonstrated. Record what changed, the evidence and the date. If a discovery changes an earlier risk conclusion, identify that consequence explicitly instead of hiding it in an inventory update.
Set review triggers such as a new service, supplier change, acquisition or retired system. A one-time discovery exercise becomes stale unless ordinary change processes keep the picture current.
Use the assessment scope to distinguish deliberate exclusions from omissions. Then assess which information needs protection with the relevant service owners.
Your next action
Choose one important service and ask its users to show the ordinary process and its fallback. Compare the resulting information and system list with the assessment, then investigate the most consequential omission.
The paid SRMBOK Information and System Value Assessment v5.0 provides a workbook for recording service elements, ownership and the consequences of information or system compromise. Calibrate its illustrative criteria to your organisation; a completed workbook does not authorise sharing or prove the systems are adequately secured.