A system record represents a component that supports the organisation's activities. Your inventory can include applications, platforms, infrastructure, data, facilities or other components appropriate to your architecture and assessment scope.
Define the record boundary
Choose a level of detail the team can maintain. For example, a customer platform may be one system with documented dependencies, while a separately operated database service may need its own record. Explain what is included and excluded so assessments do not silently use different boundaries.
Use Complementary information to record interfaces, dependencies and shared responsibilities that do not fit the structured fields. Link relevant third-party records where supported.
Distinguish classification fields
Architectural domains describes the part of the architecture represented by the system. System domains and System types provide further classification. Lifecycle status describes its stage, while Criticality reflects its business significance. These fields answer different questions.
Avoid inferring criticality solely from a technology label. Explain which business activity depends on the system and what a loss of confidentiality, integrity or availability would mean in that context.
Review catalogue vocabulary
Open Databases → Configuration to inspect the workspace's system and cross-module catalogues. Available entries can be adapted where editing is permitted; do not assume that a screenshot's list is a fixed universal taxonomy.
Agree definitions before widespread use and review the effect of later wording changes. Hiding an entry affects future selection while existing records can retain their stored values.
Use the resulting classification to support filtering and review. It organises information; it is not a substitute for a risk assessment of the actual system and its dependencies.