ID.AM-07 Data inventory and metadata: requirements and evidence

What ID.AM-07 data inventory requires and why auditors ask about it

A customer questionnaire, a regulator's request or an internal audit may ask for proof that you know where your sensitive data lives. ID.AM-07 asks an organization to keep inventories of its designated data types and their metadata current. Those designated types typically include personal information, health information, financial account numbers and intellectual property, and the inventory should record enough about each one (classification, owner, provenance and location) that someone can act on it. ID.AM-07 is a Subcategory of the Asset Management (ID.AM) Category in the IDENTIFY Function of the NIST Cybersecurity Framework (CSF) 2.0, which NIST published as CSWP 29 on February 26, 2024. The Category sits alongside the hardware, software, supplier service, network flow and prioritization Subcategories, so auditors often read ID.AM-07 together with them.

A data inventory differs from a hardware or software inventory in what it describes. A device or application is a discrete object that a scanner or agent can find and count. Data is copied, exported, cached and shared, so the same customer record may sit in a database, a ticketing system, a spreadsheet and a vendor's platform at once. Metadata also goes stale quickly: a classification assigned in one review cycle may not match the content a year later, and the owner named in the register may have left the company. NIST's Implementation Examples for ID.AM-07 point to continuous discovery of new instances and tagging of data with classifications, which signals that a one-time spreadsheet will not satisfy the outcome. The organization owns this result. NIST does not certify or endorse products, implementations or services, and no independent body issues a CSF certificate, so an assessor will test the inventory you actually run.

Before any tooling work, confirm which data types your contracts, regulators and internal policies name, because those define the scope of the inventory. Then ask the data owners who will answer for each type and what evidence they can show, such as a dated export of the register, classification tags and the discovery results behind them. The CSF 2.0 Reference Tool lists informative references for ID.AM-07, which you can use to check which other standards your auditors may map to the same practice. Confirm those references against the current NIST publications before you cite them in a response, since NIST updates them separately from the framework.

Which data, systems and teams fall inside an ID.AM-07 inventory

An ID.AM-07 inventory is only as complete as its boundary. The cards below cover the decisions that set that boundary: which data types are designated, where that data lives, who holds it outside your walls, and who answers for it. NIST leaves each of these choices to the organization, informed by its Implementation Examples.

Designated data types

The data types you choose to list are an organizational decision. NIST's Implementation Examples for ID.AM-07 name PII, PHI, financial account numbers, intellectual property and OT data as examples to consider. Start with the types your contracts, regulators and customers already name, then add others your risk assessment identifies. Record the reason each type is in scope so an assessor can see the decision was deliberate.

Repositories and SaaS stores

Designated data rarely sits in one database. Scope should cover file shares, object storage, databases, backups, data warehouses, email archives, collaboration tools and SaaS applications where staff store records. Confirm which of these your teams actually use, including exports and copies made for reporting. Each store you omit is a place where an unlisted instance can appear without anyone noticing.

Data held by third parties

Data you hand to a processor, cloud provider or managed service still belongs in your inventory if you are accountable for it. The inventory should record which external service holds each designated type and where that data is located. Cross-check these entries against your supplier services inventory under ID.AM-04 so no external store is missing from either list.

Operational technology data

OT environments generate designated data such as process historian records, engineering files and sensor data that may be sensitive to the operation. Some of these systems sit outside the IT discovery tools you already run. Decide whether OT data is in scope for this inventory, and if it is, name the engineering or plant teams responsible for each dataset and confirm how their systems are discovered.

Data owners and custodians

Every inventoried dataset needs a named owner who decides how it is used and a custodian who operates the system holding it. Owners are often business leads, not IT staff, so assign them explicitly. Ask each team to confirm which datasets they own, and record gaps where no one accepts ownership. An unowned dataset cannot be classified or reviewed, which is why this card matters for the rest of ID.AM-07.

Legal and contractual obligations

Some data types enter scope because a law or contract requires it, such as personal data under GDPR or health data under HIPAA. Involve legal and privacy teams when setting the designated list, since they can name the obligations your inventory must support. Keep a short record of which requirement drove each inclusion so the scope can be explained to an auditor or customer.

How an assessor tests the ID.AM-07 data inventory

This table sets out what an assessor checks for each element of ID.AM-07, the evidence they ask for, and the findings that most often come up. Read it as a checklist for your own pre-assessment review: if a row's evidence does not exist yet, that element will likely be a finding.

Element	How the assessor tests it	Evidence requested	Common findings
Inventory exists and is current	Confirms a data inventory exists, then selects several systems and compares recorded datasets with what is actually stored there and the date of the last update.	The inventory itself, with version history and last-reviewed dates; a sample of systems traced to their inventory entries.	Inventory exists only as a one-time spreadsheet with no update date; systems added since the last review are missing.
Designated data types are defined	Checks that the organization has written down which data types it designates for inventory (for example PII, PHI, financial account numbers, intellectual property or OT data) and that the list matches its obligations.	A data classification or designation standard, approved by a named owner, mapped to legal and contractual obligations.	Categories are generic ("confidential") with no definition, or the list omits data types the organization's own contracts or regulations name.
Discovery is ongoing	Asks how new instances of designated data are found after go-live, and tests whether discovery runs on a schedule or on events, not only at project kickoff.	Discovery tool configuration and scan schedules, scan reports, and records of new findings added to the inventory.	Discovery was run once for an audit; no record exists of scans after the first run or of how new stores are detected.
Classification labels are recorded and applied	Samples datasets and checks whether the label on each one matches the designated classification scheme and whether labels are applied in the systems themselves.	Labeling rules, tagged records or metadata exports, and a sample of labeled objects with their classification.	Labels exist in the policy but are blank or default on most datasets; labels differ between teams for the same data type.
Owners are named	Selects datasets and confirms each has a named accountable owner with an authority to approve access and retention decisions.	Owner assignments per dataset, with the owner's acknowledgement or role description.	Datasets without an owner, or owners who have left the organization and were never replaced.
Provenance is traced	Follows a sample of datasets back to their source system or the process that created them and checks whether that origin is recorded.	Lineage or source records, data flow documentation, and the source system named in each inventory entry.	Datasets copied from other systems with no record of origin, especially exports shared through spreadsheets or email.
Location is recorded	Checks whether each inventory entry names the system, storage location and jurisdiction where the data resides, including cloud regions and backups.	Location fields per entry, cloud account and region listings, and backup target records.	Backups, replicas and analytics copies are missing from the inventory, so their location is unknown.
Inventory is used in decisions	Asks how the inventory feeds access reviews, retention, risk assessments, backup scope and incident response, and looks for records showing those uses.	Access review records, retention schedules, risk register entries and incident tickets that refer to inventory data.	The inventory is kept for audit only and is not consulted when access is granted or when an incident needs to scope affected data.

How to build a data inventory that meets ID.AM-07

This sequence turns ID.AM-07 from a sentence in the framework into a working data inventory: defined data types, a metadata schema, discovered and owned records, and a review cycle that keeps the inventory current as data moves.

Define the designated data types
Start by agreeing which data types the organization must track. Typical starting points are personal data, health information, financial account numbers, intellectual property and, where present, operational technology data, which are the types NIST lists in its Implementation Examples for ID.AM-07. Legal, compliance, privacy and business owners should confirm the list against their contracts and regulations, since the framework does not fix it for you. The output is a short, approved register of data types with a one-line definition for each, signed off by the accountable owner.
Set the metadata schema
Define the fields every inventory record must carry: classification label, data owner, provenance (where the data came from and under what basis), storage location and, where relevant, geolocation. Keep the schema small enough that owners can complete it. Agree the allowed values for each field, such as the classification levels the organization already uses, so tagging is consistent across teams. The output is a written schema and a sample record that the security and privacy teams have reviewed.
Run discovery across repositories
Locate where designated data actually lives. Discovery covers databases, file shares, cloud storage, SaaS platforms, backups, endpoints, logs and exports shared with third parties. Automated scanning tools can help, but they produce false positives and miss unstructured data, so pair them with interviews with system and business owners. The output is a candidate list of repositories and data stores, each linked to the data types found in it, along with a note of where discovery was manual or incomplete.
Assign data owners
Name one accountable owner for each data set or repository. The owner is usually a business or system role rather than the IT administrator who hosts the data, and the owner decides classification and approves access. Record the owner in the inventory and confirm the assignment in writing. The output is a populated owner field for every record, with gaps listed as open actions until someone accepts responsibility.
Tag and classify each record
Apply the agreed classification label, provenance and location details to every record in the inventory. Where tagging is automated, check a sample by hand before relying on it, because automated labels drift and need review. Record how each tag was set, whether by scan, owner declaration or system integration, so an assessor can see the basis for the label. The output is a complete, tagged inventory with a documented method and a list of records still awaiting owner confirmation.
Connect the inventory to asset and access processes
Link data records to the hardware, software and service inventories covered by ID.AM-01 to ID.AM-04, so each data set can be traced to the system that holds it. Tie the classification labels to access reviews and backup or retention decisions, so a change in label changes the controls that apply. The output is a working cross-reference between the data inventory and the asset inventory, plus one example of a classification change that flows through to an access or backup decision.
Set a review cadence and triggers
Define how often owners confirm their records and which events force an update outside that cycle, such as a new system going live, a new third-party data flow, a merger or a change in regulation. Keep a change log so the inventory's history can be shown to an assessor. The cadence should be set by the organization's own risk decisions and documented in its policy. The output is an approved review schedule, a list of update triggers and a change log that is in use.

How discovery and metadata tooling feeds the inventory

Endpoint and server tooling sees the systems that run software and store files, so it can show where designated data may sit on local disks, in user profiles and in application directories. An inventory agent can report installed software, operating system details, services and network configuration, which helps you decide which hosts need a data scan at all. It does not read the meaning of a file. A scanner can flag a spreadsheet that matches a pattern for account numbers, but it cannot tell whether the file is a test fixture, a copy, or the authoritative record, so owner and classification still need a person or a rule.

What discovery sees: host identity, installed applications, services, open ports and user accounts on each managed machine.
What it misses: data stored on unmanaged laptops, personal devices, or hosts that never enrolled with the agent.
Where manual entry remains: assigning an owner and classification label to each data repository found on a host.
Continuous coverage: agents that report on a schedule reveal new hosts and new software between audits, which keeps the host list current.
Data location: content scanning can locate matches, but the record should still name the business owner and the system of record.

Before you rely on endpoint data for ID.AM-07, confirm that every server and workstation class reports to the inventory and that the scanning rules match your designated data types.

Evidence that passes an ID.AM-07 review and how to keep it current

An ID.AM-07 review looks for a data inventory that is written down, owned, classified and kept current, not a one-time spreadsheet. The artifacts below connect the register, the exported inventory, the classification rules and the discovery evidence, so each one can be traced to the others between assessments.

Data type register

This is the list of designated data types the organization has decided to track, such as personal data, health information, financial account numbers and intellectual property. It is the starting point for ID.AM-07 because every later artifact must map back to it. Check that each entry names its data type, the systems where it is expected to live, and the business reason it is tracked. Review the register when a new product, regulation or contract adds a data category, and record the date and approver of each revision.

Exported inventory with metadata fields

The inventory is the dataset itself: one row per data store or dataset, with fields for classification, owner, provenance, location and last-reviewed date. An assessor will sample rows and ask where each came from. Confirm that the export is dated, that it comes from the system of record rather than a hand-edited copy, and that blank owner or classification fields are counted and reported rather than silently omitted.

Classification policy and labeling rules

The classification policy defines the labels used in the inventory, what each label means and which handling rules follow from it. For ID.AM-07, the key evidence is that tagging is applied consistently, so the policy should state who may assign or change a label and how mislabeled data is corrected. Keep the policy version-controlled and link each label to the controls that protect it, so the inventory and the protection requirements stay aligned.

Named data owner assignments

Each data type and each dataset needs a named accountable owner, not a team alias. Assessors check whether the owner is still employed, still in the role, and aware of the responsibility. Keep an owner list that is reviewed when people change roles or leave, and record acceptance of ownership. Where ownership is shared across business and IT, document which party decides classification and which party maintains the records.

Discovery scan reports

Discovery reports show how the organization finds data it did not register, such as copies in file shares, collaboration tools or new cloud buckets. NIST's implementation examples expect new instances to be found continuously, so scan schedules, scope, coverage gaps and the count of unregistered findings are the evidence to keep. Retain reports from each scan cycle and show how each finding was either added to the inventory or closed with a reason. Confirm which environments the scans cannot reach.

Change records and review sign-offs

Change records show that the inventory moved when systems moved: new datasets added, owners reassigned, labels corrected and locations updated, each tied to a ticket or change request. Periodic review sign-offs by the data owner and the security lead confirm that the inventory was checked, with the date and the scope of the check. Between audits, set a review cadence the organization can actually sustain and track overdue reviews as an open finding rather than letting them lapse.

What a data inventory costs in money and effort

This table breaks down the cost components of an ID.AM-07 data inventory, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for scoping and for questions to put to a quote, since no price is stated for any component. The main takeaway is that open-source discovery tooling removes license spend but leaves the labor of labeling, owner sign-off and evidence upkeep in place.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Discovery tooling or licenses	Commercial vendor, or internal platform team if self-hosted open source	Commercial licenses recur; open-source software carries no license fee but still needs hosting	Number of repositories, file shares and databases scanned; data volume; whether discovery runs continuously
Engineering time to integrate sources	Platform or data engineering staff, or an implementation partner under a written scope	One-time per source, plus change work when systems are added	Number of repositories, connector availability, age and access model of each source
Data owner time for labeling	Business owners and data stewards who confirm types, classifications and owners	One-time for the initial pass, recurring for new datasets and reclassification	Number of datasets, unclear ownership, number of regulated data types in scope
Provenance and location mapping	Engineers and architects who trace data origin, copies and geolocation	One-time for the baseline, recurring as flows change	Count of cross-border copies, third-party transfers and derived datasets
Evidence upkeep	Compliance lead and system owners who keep inventory exports, change records and review sign-offs current	Recurring on each review cycle set by the organization	Review frequency, number of systems feeding the inventory, how often data stores change
External review and auditor sampling	Independent auditor or assessor who samples the inventory; the organization pays the auditor's fees	Recurring with each assessment cycle	Scope of the assessment, number of samples chosen, quality of existing records
Self-hosted open source trade-off	Hosting and operations staff remain paid even when license spend is removed	Recurring operations effort; hosting costs depend on the client environment	Team skills, support model and whether discovery data must stay inside the client's own network

How self-hosted open source supports the data inventory

GLPI and Wazuh record the systems that hold data, but they do not classify the data itself. GLPI's Assets module tracks computers, software, network equipment, printers, phones and racks, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint and stores them in the Wazuh indexer. Together they answer the first half of ID.AM-07: which servers, workstations and applications exist, and what software runs on them. That gives you a defensible starting point for locating where designated data types such as PII, PHI or financial account numbers may reside, which the Subcategory's Implementation Examples expect you to connect to.

The second half of ID.AM-07 is harder to automate. Labeling data by content, tagging classifications, recording owners and tracking provenance and geolocation require discovery tooling that reads or fingerprints data stores, plus a classification policy that defines the labels. Neither GLPI nor Wazuh is described in the supplied sources as doing content discovery or classification, so do not assume they do. Before scoping the work, ask the vendor or your integration partner which data discovery, tagging and owner-attribution features exist in the version you plan to run, and whether any of them are native or require custom development. Where they do not exist, plan for a separate data discovery capability and for manual owner attestation, and budget that effort explicitly.

A practical next step is to map each inventoried system from GLPI or Wazuh to the data types it is expected to hold, then flag every system where that mapping is unknown. Those gaps become the work list for data discovery and owner assignment. Keep the mapping under change control so it stays current, since ID.AM-07 concerns inventories that are kept up to date. An assessor will likely ask how a new data store is detected and recorded, so confirm that the GLPI or Wazuh inventory feeds that process, and document which step relies on people rather than tooling.

Where organizations fall short on ID.AM-07 and how to close each gap

Most ID.AM-07 shortfalls are not missing tools. They come from undefined scope, inventories that go stale, datasets nobody owns, and classification that never reaches the systems that hold the data. The cards below pair each gap with a closing action you can assign, test and evidence.

No agreed list of designated data types

Without a written list of which data types the organization designates, such as personal data, health information, financial account numbers and intellectual property, every team decides for itself what counts. Agree the list first and approve it at the level that owns data risk. For each type, record the legal or contractual reason it is designated and the systems expected to hold it. Check that the list matches the data types named in your regulatory and customer obligations.

Inventories built once and never refreshed

A data inventory compiled for an audit starts drifting the day it is finished, as new applications, exports and cloud buckets appear. ID.AM-07 expects the inventory to stay current, which means discovery must run continuously rather than as a periodic project. Pair scheduled discovery scans with a rule that new systems cannot go live until their data types are recorded. Check how long it takes for a new data store to appear in the inventory.

Unowned shadow datasets

Spreadsheets, analytics extracts, test copies and departmental databases often hold designated data with no named owner. When an incident or access request arrives, nobody can answer for them. Every dataset in the inventory needs one accountable owner, and unowned datasets should be flagged as a finding, not silently accepted. Discovery tools can find these stores, but a person must still be assigned to decide whether each one is kept, moved or deleted.

Classification labels that exist only on paper

A classification policy with four levels means little if no system applies the labels. Data tagged in a spreadsheet but untagged in storage, databases or file shares cannot drive access control, retention or encryption decisions. Check whether labels are stored as metadata in the systems that hold the data, not only in the document that defines them. Sample a set of records from each designated type and confirm the label matches what the system reports.

Missing provenance and location records

Knowing that a dataset contains personal data is less useful if you cannot say where it came from, which system copied it, or which country or cloud region hosts it. Those gaps block breach scoping and transfer analysis. Record the source system, the transformation or export that created each copy, and the storage location as fields in the inventory. Test by tracing one designated record from its origin to every copy, and confirm the inventory shows all of them.

Ownership gaps in the inventory workflow

Inventories often fail at handoffs: the data owner assumes IT maintains the record, while IT assumes the business reviews it. ID.AM-07 is met only when someone checks the inventory on a set schedule and records the outcome. Assign a named reviewer to each data domain and keep dated review records as evidence. Ask for the last review date and the list of changes made in that review for a sample of domains.

Who owns the data inventory and who can help

The organization owns its data inventory. Only the organization can decide which data types count as designated, who is accountable for each data set and how classifications map to business decisions. NIST's Implementation Examples for ID.AM-07 describe activities such as listing designated data types, tagging data with classifications and recording owner and location, and these activities depend on people who know the business and the systems that hold the data. Data owners approve classifications and answer provenance questions. The security team sets the classification scheme, reviews exceptions and keeps the inventory current after system changes.

Decision rights: Name a data owner for each designated data type, such as PII, PHI, financial account numbers and intellectual property, and record who approves changes to classifications.
Classification scheme: Define the labels and the rules for applying them before any discovery tool runs, so results have a consistent meaning.
Ongoing upkeep: Assign someone to review the inventory when new systems, data flows or suppliers are introduced.
Exception handling: Decide who may accept unclassified or unowned data and how long that acceptance lasts.
Evidence ownership: Keep the inventory, classification records and approval history under the organization's own change control.

Before engaging anyone else, confirm that a named owner exists for each data set in scope.

Questions buyers ask about the ID.AM-07 data inventory

How much effort does a first ID.AM-07 data inventory take?

The effort depends almost entirely on how many systems hold designated data and how well those systems are already documented, so no fixed figure applies to every organization. Most of the work is discovery and interviews, not tooling. Expect time spent on four things: finding where personally identifiable information, protected health information, financial account numbers and intellectual property actually sit, agreeing on the data types in scope, recording a classification label, owner and location for each dataset, and recording provenance where it matters. Ask any advisor to scope the first pass by named systems and data types in a written plan before work starts, since that scope is what drives the quote.

Can a small team build a data inventory on its own?

Yes, a small team can start on its own if it limits scope to its most important data types and systems. NIST's Small Business Quick-Start Guide (SP 1300) cites ID.AM-07 when it suggests that small businesses prioritize inventorying and classifying their business data, which makes this a sensible first step rather than a full program. The limit is usually people, not tools: someone has to hold the discovery work, keep the list current and get decisions from the business. If that person also runs IT operations, plan for the inventory to slip. Outside help is most useful for the initial design of the data types, labels and owner model, after which the team can maintain the register.

What does a data inventory need from data owners?

A data inventory needs named business owners who can say what a dataset is for, who may use it and how long it must be kept. Technical teams can find where data lives, but only the owner can confirm its classification, the legal or contractual reasons behind it and the approved location. Ask each owner for four things: the datasets they are accountable for, the classification they agree to, any regulatory tags such as health or payment data, and who approves changes. Owners will push back when they are asked to review long lists with no context, so give them a short, pre-filled draft per business area. Record the owner in the inventory itself so the record stays useful after staff changes.

How long does it take to keep a data inventory current?

The ongoing effort is smaller than the first pass, but it recurs for as long as the organization creates, moves or retires data. Each new system, integration, cloud account or data export can add designated data that the register does not yet show. NIST's Implementation Examples for ID.AM-07 describe continuously discovering new instances of designated data, which points to automated discovery combined with a review cycle rather than a yearly exercise. Set the review frequency based on how fast your data estate changes, and agree on triggers such as new projects, vendor onboarding and system decommissioning. Confirm with any advisor exactly what they will maintain and what remains your team's responsibility.

Does NIST certify that an organization meets ID.AM-07?

No. NIST does not certify organizations, products or services against the CSF, and it states that it has no plans to develop a conformity assessment program. The CSF is voluntary for most organizations, and NIST is not a regulatory agency. Your customers, contracts or regulators may ask you to show alignment with ID.AM-07, so the evidence you keep is your own: a documented inventory, classification and owner records, and dated review logs. Any statement that an organization is "NIST certified" for ID.AM-07 should be challenged. Confirm what the requesting party accepts as evidence before you start.

When should an organization bring in outside help for its data inventory?

Bring in outside help when the data estate is large, spread across several clouds or business units, or subject to rules that the internal team cannot interpret alone. Outside help is also useful when a customer or auditor will test the inventory and you need a clear independent view of gaps. DeployOpen plans, implements and documents self-hosted open-source platforms, such as GLPI for asset records and Wazuh for system inventory, inside the client's own infrastructure, and prepares evidence for compliance readiness. It does not issue audit reports or certifications; independent auditors and certification bodies do. Engagements are typically fixed-scope, with the scope agreed in writing before work begins, so ask for a written scope and a quote that follows from it.

Which tools can help keep a data inventory connected to asset records?

Asset tools cover where data sits, but they do not decide what the data is or who owns it, so pair them with a register that holds classification and ownership. GLPI's Assets module manages computers, software, network equipment and other devices, and it can receive automatic inventory from the GLPI Agent, which gives you a sound base for recording the systems that hold data. Wazuh's Syscollector module collects hardware, installed software, services and users from each endpoint for inventory views and reports. Confirm with each vendor whether a given tool can discover data stores or tag data by sensitivity before you rely on it for that purpose, since these tools are documented primarily for asset and system inventory.

What does a data inventory cost, and what drives the cost up?

Costs fall into three groups: people time for discovery, classification and owner interviews; software, which may be open source with optional support subscriptions; and outside help, if you hire it. Cost rises with the number of systems and data stores, the number of data types in scope, the quality of existing documentation, the number of owners who must be consulted, and how many regulations apply to the same data. The one-time work is the first inventory and classification scheme. The recurring work is review, discovery and label maintenance. When requesting a quote, ask for the scope in writing, the systems and data types covered, the deliverables, who maintains the register afterward and what support is included. NIST's published materials do not give a cost for this work, so use your own estimates, supported by the scope you agree.

Primary sources for ID.AM-07

Start with the Core text in Appendix A of NIST CSWP 29 before reading any secondary guidance on ID.AM-07. The Subcategory wording is short, and it sets the outcome an assessor will test: inventories of designated data types and their metadata are kept current. Read the Subcategory against your own data inventory and check whether it names the data types your contracts, regulators and customers care about, such as personal data, health information, financial account numbers and intellectual property. The NIST CSWP 29 PDF holds the full Core, so keep a copy of the exact wording in your assessment file.

Next, open the NIST CSF 2.0 Reference Tool export to see the four Implementation Examples for ID.AM-07 and the informative references attached to them. The examples cover listing designated data types, continuously discovering new instances, tagging data with classifications, and tracking provenance, owner and location. The export also links ID.AM-07 to SP 800-53 Rev. 5.2.0 controls CM-12, CM-13 and SI-12, to ISO/IEC 27001:2022 Annex A control 5.9, to SP 800-171 Rev. 3 requirement 03.14.08 and to CIS Safeguard 3.2. Confirm each mapping against the source framework before you cite it in an audit, because mappings are reference material and do not replace the source text.

If you are moving from CSF 1.1, the NIST CSF 1.1 to 2.0 Core transition spreadsheet shows that ID.AM-07 absorbs part or all of CSF 1.1 ID.AM-3. Use it to find older evidence you can reuse and to see where the scope has changed. For a smaller organization, the NIST SP 1300 Small Business Quick-Start Guide cites ID.AM-07 when it suggests that small businesses first inventory and classify their business data. Treat it as a starting plan, not as proof that the Subcategory is met, and ask your assessor which of its steps they expect to see as evidence.

ID.AM-07 Data inventory and metadata