Summary
Organizations must maintain a current, accurate inventory of all systems operating in production. Each inventory record must capture system ownership — including designation of a system manager who is an active employee — along with system criticality classification and data classification. The inventory must be linked to the developer toolchain and SDLC systems and it must be reviewed and updated on a defined cadence and upon any material change.
Description
A well-governed system inventory is foundational to an organization’s risk management, compliance, and operational resilience posture. Financial services organizations operate complex, interconnected technology estates spanning on-premises infrastructure, cloud platforms, third-party hosted services, and internally developed applications.
Without a reliable and current inventory, organizations cannot consistently apply security controls, assess blast radius during incidents, fulfill regulatory obligations, or make informed decisions about system decommissioning and lifecycle transitions.
This control establishes the minimum requirements for maintaining a system inventory that is accurate, ownership-attributed, and enriched with the metadata necessary to support downstream risk and compliance processes. The inventory serves as a system of record that feeds into change management, access control, vulnerability management, business continuity planning, and regulatory reporting workflows.
Requirements
- Inventory Scope
The inventory must include all systems operating in production, defined as any system that: Supports a business process, customer-facing service, or internal operational function; Stores, processes, or transmits organizational or customer data; or Integrates with or has a trust relationship to another in-scope system.
- Inventory Attributes
Each inventory record must capture a set of attributes such as: System Name, System ID, System Description, System Manager, System Criticality Tier classification, Data Classification, Lifecycle Status (Active / Sunset Planned / Decommissioned)
- Inventory Maintenance
The inventory must be reviewed in its entirety no less than annually, with individual records updated within 30 days of any material change (e.g., new system launch, change of System Manager, re-classification, decommission).
A new system must be added to the inventory prior to or concurrent with its promotion to production. Systems must not enter production without an assigned System Manager and completed classification attributes.
When a System Manager separates from the organization or changes roles, an updated System Manager must be designated and reflected in the inventory within 5 business days.
-
System Criticality Classification - for example: Tier 1 - Business Critical, Tier 2 - High Criticality, Tier 3 - Medium Criticality, Tier 4 - Low Criticality.
-
Data Classification - for example Restricted, Confidential, Internal, Public
-
Linkage to Developer Toolchain and SDLC Systems
Each inventory record must be traceable to its corresponding source code repository (e.g., GitLab, GitHub), CI/CD pipeline configuration, and artifact registry, enabling a continuous chain of custody from code commit through production deployment. This linkage ensures that changes to a production system are always attributable to an inventoried, ownership-attributed entity, and that pipeline-enforced controls — such as security scanning, compliance gates, and deployment policies — can be scoped and validated against a known system baseline.
- Tooling and Access
The inventory must be maintained in a centralized, access-controlled system of record. Read access should be broadly available to authorized internal stakeholders. Write access must be controlled and auditable. The inventory system must support export and reporting capabilities to facilitate governance reviews and audit requests
Examples & Commentary
Example 1 — New System Onboarding
A development team completes build and testing of a new customer-facing loan origination portal and prepares for production deployment. Prior to the production release, the team’s technology lead is designated as System Manager and the system is registered in the inventory with a criticality of Tier 1 (Mission Critical) — as it directly supports a revenue-generating customer process — and a data classification of Tier 1 (Restricted) due to the presence of PII and NPI. The inventory record is completed and approved before the deployment pipeline is authorized to promote the build to production.
Example 2 — System Manager Departure
The System Manager for a core risk calculation engine notifies HR of their resignation, with a last day in 10 days. Upon notification, the technology risk team triggers a System Manager transition workflow. A successor — a senior engineer on the same team — is designated and the inventory record is updated within 3 business days of the original System Manager’s departure, well within the 5-business-day requirement.
Example 3 — Classification Disagreement
During an annual inventory review, a data engineering team classifies their internal analytics platform as Tier 3 (Internal) for data classification, reasoning that the platform only contains aggregated metrics. Upon review, the risk team notes that the platform ingests and temporarily retains raw transaction records during ETL processing, which includes cardholder data. The classification is escalated and updated to Tier 1 (Restricted), triggering a review of the platform’s encryption posture and access control configuration.
Links
This control maps to asset inventory and lifecycle management requirements across five frameworks applicable to financial services organizations.
| Framework | Provision | Applicability | Link |
|---|---|---|---|
| FFIEC IT Handbook | Info Security II.C.5; AIO III.B.1 | US-supervised depository institutions, BHCs, and TSPs | ithandbook.ffiec.gov |
| NIST SP 800-53 Rev 5 | PM-5 (System Inventory); CM-8 / CM-8(4) | US federal agencies; FS best practice baseline | PM-5 · CM-8 |
| SOC 2 TSC (AICPA) | CC6.1 — Inventory of Information Assets | Service orgs with SOC 2 audit obligations | aicpa-cima.com |
| PCI DSS v4.0 | Requirement 12.5.1 — System Component Inventory | Organizations in scope for cardholder data protection | pcisecuritystandards.org |
| EU DORA | Article 8 — Identification; Articles 28–30 (third-party register) | All EU financial entities; effective January 17, 2025 | eur-lex.europa.eu |
FFIEC
The IT Handbook describes principles rather than prescriptive requirements. This control produces the evidence base — documented inventory, ownership, classification, and review records — that examiners typically request during examination cycles.
NIST: PM-5 vs CM-8
This control operates at the PM-5 level (organizational system inventory) rather than CM-8 (individual component inventory). Organizations should maintain both: this control satisfies PM-5 and anchors downstream CM-8 compliance. The System Manager attribute directly satisfies CM-8(4) — Accountability Information.
SOC 2: CC6.1, not CC6.3
The inventory obligation sits in CC6.1. CC6.3 addresses role-based access authorization and is a downstream consumer of the inventory this control produces, not a direct inventory requirement itself.
PCI DSS
Organizations subject to PCI DSS should ensure the data classification attribute explicitly flags Tier 1 (Restricted) systems that are in scope for PCI, and should maintain network diagram traceability as a supplemental artifact.
EU DORA
The criticality classification supports DORA’s identification of critical and important functions; Non-EU organizations with EU operations should assess applicability; analogous requirements exist under the UK FCA’s operational resilience rules (PS21/3 and PS24/16).