What Safeguard 3.2 asks you to know about your data
Safeguard 3.2 asks you to establish and maintain a data inventory that covers, at a minimum, all of your sensitive data, built from your data management process and reviewed and updated at least once a year, with sensitive data handled first. If an auditor or customer asks whether you know where sensitive data lives, the honest answer has to be a current, written record, not a recollection. The Safeguard sits in the Data asset class and the Identify security function, and it is assigned to all three Implementation Groups, so it is part of the IG1 essential cyber hygiene baseline that every enterprise is expected to meet.
The difficulty is that sensitive data rarely stays where it was first stored. Copies appear in shadow spreadsheets, email attachments, ad hoc exports, backups, developer test environments and software-as-a-service tools that teams adopt without central review. Each copy can outlive the system it came from, and few carry labels that identify their sensitivity. A useful starting point is to ask each business owner which systems hold customer, employee, financial or regulated records, then check those answers against identity provider application lists, cloud account resources, database catalogs and SaaS admin consoles. Discovery tools can help, but they only find what they are pointed at, so the inventory should record scope and the locations you deliberately excluded.
Start from the data management process described in Safeguard 3.1, since it defines which sensitivity levels exist and who owns each data set. For each data store, record the owner, the sensitivity, the system or service holding it and the date it was last verified. Confirm with your assessor exactly how they will test currency, because the CIS assessment specification treats an inventory that has not been updated for more than 12 months as a failure. Keep the inventory in a version-controlled location so changes and reviews leave a trail. Because it feeds Safeguards 3.3 through 3.5 and 3.7, gaps here will surface later in access control, retention, disposal and classification work.
Which data stores and teams fall inside the inventory
Safeguard 3.2 asks for an inventory of data, at minimum all sensitive data, and the scope of that inventory is set before anyone counts a single table or bucket. Sensitivity definitions from Safeguard 3.1 decide which stores, copies and providers must be listed, so the scoping decisions below shape most of the work.
On-premises databases and file shares
Start with the stores your teams already know about: production databases, reporting replicas, departmental file shares and shared drives. Record the owner, the sensitivity label from the data management process and the schema or folder structure where sensitive fields sit. Check for copies created by exports, ad hoc extracts and spreadsheets, because these often fall outside the formal inventory and are where sensitive data is most often missed.
Cloud storage and managed databases
Object storage buckets, managed databases and cloud file services are easy to create and easy to forget. Inventory every account and region, including sandbox and test projects that were loaded with production extracts. Confirm who can create new storage so that the inventory is updated when a new bucket appears, not only when an audit is scheduled.
SaaS platforms holding business records
Customer relationship tools, ticketing systems, HR platforms and collaboration suites often hold the largest volume of personal and confidential data outside core systems. List each platform, the data categories it stores, the tenant or workspace that holds them and the administrators who control retention. Ask the business owner, not only IT, which platforms contain sensitive records.
Backups and recovery copies
Backups copy sensitive data, sometimes in places with weaker access controls than the source system. Include backup repositories, snapshots and archive tiers in the inventory, and record their retention and location. Confirm that restores and disposal under Safeguard 3.5 can reach these copies, because an inventory that ignores backups understates the data an incident could expose.
Endpoints and removable media
Laptops, desktops and mobile devices store local copies of files, downloads, synced folders and mail caches. Use the enterprise asset inventory from Safeguard 1.1 as the starting list of devices, then decide which endpoints are expected to hold sensitive data. Where a device is known to hold sensitive data, record that fact in the data inventory so that encryption and disposal decisions can follow.
Logs and data held by service providers
Application and audit logs can contain personal data such as IP addresses, user identifiers and request payloads, and logs are often retained for longer than the source data. Add log stores to the inventory with their retention periods. Data held by service providers belongs in scope too, so ask each provider which sensitive data it stores or processes and record it in the inventory alongside Safeguard 15 provider records.
How the data inventory differs from the asset and software inventories
Safeguard 1.1 asks the enterprise to inventory its enterprise assets, meaning the physical, virtual and cloud devices that connect to its networks. The record answers the question of what hardware and endpoints exist and where they sit. Ownership usually sits with IT operations or the platform team, because they manage provisioning, asset tags and cloud resource records.
- What it records: device identifiers, owner or department, network address, location and the asset class of each device.
- Primary question: which devices are on the enterprise network, and which of them are authorized?
- Owner: typically IT operations or platform engineering, with updates driven by provisioning and decommissioning.
- Link to the other inventories: the software inventory is tied to these device records, and the data inventory uses them to find where sensitive data is stored.
- Why it matters for 3.2: the Assessment Specification lists Safeguard 1.1 as a prerequisite for measuring 3.2, because it typically produces the device data the measurement needs.
Before you assess Safeguard 3.2, confirm that your asset inventory is current enough to name every system that holds sensitive data.
Safeguard 2.1 asks the enterprise to maintain an inventory of the software running on its assets, including operating systems, applications and their versions. The record answers the question of what software runs in the enterprise and whether it is supported and authorized. Ownership typically sits with IT, security operations or the application owners who approve what is installed.
- What it records: software titles, versions, publishers, the assets they run on and their support status.
- Primary question: what software is installed and running, and is each item approved and still supported?
- Owner: typically IT operations or security, with application owners confirming business use.
- Link to the other inventories: each software record points back to a device in the asset inventory, and the software that processes data is what determines where that data lives.
- Limit for 3.2: a software list shows that an application exists, but it does not show what data the application holds or how sensitive that data is.
Confirm which applications process sensitive data, because those applications will need entries in the data inventory.
Safeguard 3.2 asks the enterprise to inventory its data, at a minimum all sensitive data, following the data management process from Safeguard 3.1. The record answers the question of what data the enterprise holds, how sensitive it is and where it is stored. Ownership is usually shared between data owners who set sensitivity and the security or privacy function that maintains the register.
- What it records: data sets or categories, sensitivity level under the data management process, data owner, the systems and assets that store or process them, and the review date.
- Primary question: what sensitive data do we hold, where does it live and who is accountable for it?
- Owner: data owners for content and sensitivity, with the security or privacy team maintaining the register.
- Link to the other inventories: each data entry points to the devices and software that store it, so the asset and software inventories supply the locations.
- Review: the Safeguard requires the inventory to be reviewed and updated at least annually, with sensitive data reviewed first.
Ask the data owners to confirm that each sensitive data set has a named system of record that appears in your asset and software inventories.
The three inventories are separate records, but they depend on each other. The asset inventory names the hardware, the software inventory names what runs on it, and the data inventory names what sensitive content those systems hold. A gap in the first layer makes the third layer incomplete, because an unknown server cannot be checked for sensitive data.
- Dependency order: devices first, software second, data third, which matches the prerequisite that the Assessment Specification sets for 3.2.
- Shared keys: use one identifier for each system across all three records so an assessor can trace a data set to a device.
- Gap check: list systems in the data inventory that do not appear in the asset inventory, and treat each one as a finding.
- Downstream use: Safeguards 3.3, 3.4, 3.5 and 3.7 depend on the data inventory, so errors here spread to access control, retention, disposal and classification.
- Illustrative example: a reporting database appears in the data inventory but not in the asset inventory, which means its host has no owner and no patch record.
Ask your tooling team whether the three records can share identifiers or be linked by a common export.
How an assessor tests the data inventory
This table walks through what an assessor checks for Safeguard 3.2, what evidence they ask for, how they sample, and where inventories usually fail. Use it to prepare the evidence pack before an assessment and to find gaps in your own inventory.
| Assessor check | What the assessor looks for | Where it usually fails |
|---|---|---|
| Inventory exists | A documented data inventory covering enterprise data, with all sensitive data included as a minimum | No inventory exists, or it is a list of systems with no data types or sensitivity recorded |
| Follows the data management process | Inventory fields and sensitivity levels match the definitions in the Safeguard 3.1 data management process | Inventory uses its own labels, so sensitivity levels cannot be traced back to the policy |
| Sensitivity mapping | Each data set is mapped to a sensitivity level, and the mapping can be checked against the data management process | Data sets are listed without a sensitivity value, or most entries are marked as unclassified |
| Storing assets mapped | Each data set links to the assets, applications and locations that store it, using the asset and software inventories as a reference | Data is linked to a server name only, leaving out databases, file shares, endpoints and backups |
| Currency within 12 months | A review date and a change history show the inventory was updated within the last 12 months, with sensitive data reviewed first | Last-updated date is older than 12 months, or the review date was not recorded |
| Coverage of SaaS and cloud stores | Cloud object storage, SaaS platforms and service provider held data appear in the inventory with owners | Collaboration tools, SaaS exports, backups and developer environments are missing |
| Evidence requested | Inventory export, review records with dates and approvers, linked asset inventory extract, and the data management process it follows | Evidence is a spreadsheet with no version history, or approvals are informal emails with no record |
| Sampling approach | Assessor selects a sample of data sets and systems, then traces each back to the inventory and forward to a storing asset | Sampled systems turn up data that never appears in the inventory, which the assessor records as an exception |
How to build and maintain the inventory in six steps
This sequence turns the rules in the data management process into a written data inventory that names each sensitive store, its owner, its sensitivity and the assets and flows that carry it, with a review record kept each year.
Confirm sensitivity levels from the data management process
Start from the sensitivity levels, data owners and handling rules already defined under Safeguard 3.1. Confirm with the data owners which categories count as sensitive for your organization, such as customer records, payment data, health information or source code, and record the definitions in the inventory's header. The output is a short, approved list of sensitivity levels that every later step uses. If no approved data management process exists yet, the inventory has nothing to measure against, so confirm that gap before continuing.
Discover data stores using asset and software inventories
Use the enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1 as the starting list of places data can live. Walk through servers, databases, file shares, SaaS applications, cloud storage buckets, endpoints and backup repositories, and ask each system owner what data it holds. The asset and software lists show where to look, but they do not show what data sits inside them. The output is a discovery list of candidate data stores, each traced to a known asset or application.
Classify and record each store with owner and sensitivity
For each candidate store, record what data it holds, the sensitivity level from step one, a named business owner and a technical custodian. Sensitive stores must be recorded first, and any store that cannot be classified should be flagged for follow-up rather than left blank. The output is a populated inventory in which every sensitive store has an owner, a sensitivity level and a description of its contents. Ask the reviewer to confirm that no sensitive store is missing an owner.
Link stores to assets, software and data flows
Connect each recorded data store to the asset and software records that host it, and to the data flows that move it in or out, including flows to service providers. These links let assessors check that every sensitive store is mapped to the systems that hold it, which is the coverage the measurement looks for. Flow documentation under Safeguard 3.8 and the classification labels under Safeguard 3.7 can be referenced here. The output is a traceable record in which each sensitive store points to its hosts and its flows.
Set the annual review trigger
Set a recurring review of the full inventory, with sensitive data reviewed first, as Safeguard 3.2 requires at least once a year. Assign a named owner for the review, and add triggers for earlier updates such as new systems, new data types, mergers or changes to the data management process. Note that the CIS assessment specification fails an inventory that has not been updated for more than 12 months, so the calendar entry is a control, not a reminder. The output is a documented review schedule with an accountable owner.
Record each review and keep the history
At each review, record the date, the reviewer, what changed, which stores were added or retired and which sensitivity labels were corrected. Keep prior versions so an assessor can see how the inventory changed over time, and so you can show that updates followed the review cycle. A wiki or document system with version history, such as XWiki, or a governance tool that tracks evidence, can hold this record. The output is a dated review log linked to the current inventory, which is the evidence an assessor will ask to see first.
How completeness of the data inventory is measured
Completeness of the Safeguard 3.2 data inventory is judged on two things the CIS Controls Assessment Specification (CAS) measures: how fully the sensitive data is mapped to sensitivity levels and to the assets that store it, and how recently the inventory was updated. The specification scores the Safeguard as failing when no sensitive data inventory exists or when it has not been updated for more than 12 months. Those two conditions are the floor. Passing the mapping measure requires that each sensitive data set carries a sensitivity level from your data management process (Safeguard 3.1) and names every system, database, file share or service provider platform where it lives. Confirm the exact wording of the measures in the CAS for v8.1 before you build your reporting, because the specification describes what to measure and leaves the method to you.
A practical completeness test is sampling. Pick a set of repositories you already know hold sensitive data, such as the customer database, the HR file share, the payroll SaaS tenant and the backup target, and check each one against the inventory. For every repository, ask three questions: is it listed, is each sensitive data type in it mapped to a sensitivity level, and is the owning asset or service identified. Record misses by type, not just by count, because a missing data set in a system you already know about points to a gap in the intake process, while a missing system points to discovery. Draw the sample from several sources, including the enterprise asset inventory from Safeguard 1.1 and the software inventory from Control 2, so that the sample is not limited to systems the inventory was built from. Illustrative example: if three of twenty sampled file shares are absent, the gap is in how new shares are registered, and that is the fix to plan.
Two results follow from the sample and should drive the next decision. A miss rate that clusters in one business unit or one platform tells you where to assign an owner and where discovery tooling will pay off. Dates matter as much as coverage: record when each entry was last verified and set a review date that falls well inside the annual cycle, so the 12-month failure condition never becomes the first signal. Keep the sample results, the corrections and the reviewer's name in your version-controlled documentation. Ask your independent assessor, before fieldwork, which sampling method and sample size they will accept as evidence of completeness.
Evidence that passes a data inventory review
A data inventory is only as credible as the records behind it. The cards below cover the artifacts an assessor typically requests for Safeguard 3.2, how each one connects to the data management process and the asset and software inventories, and the routines that keep them current between audits.
The dated data inventory
The inventory itself is the primary artifact: a dated register listing data sets, their locations, sensitivity level and the systems that store or process them. Assessors check that sensitive data is covered first and that every entry names a storage location. Confirm the register records a version date and that prior versions are retained, so the review history can be shown. A spreadsheet is acceptable only if it is controlled and versioned.
The data management process it follows
The inventory must follow the documented data management process from Safeguard 3.1, which defines sensitivity levels, ownership and handling rules. Keep a cross-reference showing which sensitivity categories in the process map to which inventory entries. An assessor who finds sensitivity labels in the inventory that the process does not define will question both documents.
Owner sign-off records
Each data set should have a named owner who confirmed its entry, sensitivity level and location. Keep dated sign-off records, such as approval tickets or workflow history, that show owners reviewed their entries during the latest review cycle. Missing owner records are a common reason an inventory is treated as a list compiled by IT rather than an enterprise-owned record.
Mapping to asset and software inventories
Data sits on devices and in applications, so each data entry should link to the enterprise asset and software records from Safeguards 1.1 and 2.1. The inventory is distinct from those inventories: it tracks what data is held, while they track what runs the data. Check that every system named in the data inventory appears in the asset or software inventory, and that orphaned entries are investigated.
Review history and change records
Assessors look for evidence that the inventory was reviewed and updated at least once every 12 months, with sensitive data reviewed first. Keep a change log recording what changed, when and by whom. Version-controlled wikis or document systems can provide this history. Confirm that a review in which nothing changed is still recorded, since the review itself is the evidence.
Discovery scan outputs
Automated discovery and data loss prevention scans show whether the inventory matches what is actually stored. Retain scan reports with dates, scope and findings, and record how each unmatched finding was resolved. Scan outputs do not replace owner review, but they are the strongest check on completeness. Confirm with your team which scanning tools are in scope and how their results feed the inventory.
What a data inventory costs in money and effort
This table breaks down the cost components of building and keeping a sensitive data inventory under Safeguard 3.2, who is paid for each one, and whether it is one-time or recurring. Use it to shape an itemized quote, since no price or duration for this work is published in the supplied facts and the real figures depend on your environment.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Discovery tooling or licenses | Software vendor, or your team if a self-hosted open-source tool is used | Licenses recur if commercial; open-source tools remove license spend but still need hosting and staff time | Number of repositories, file shares, databases and SaaS applications in scope |
| Initial inventory build | Data owners, system owners and an implementation partner or internal team | One-time | Number of data stores and how many lack named owners or documented sensitivity levels |
| Engineering time to connect sources | Internal platform or security engineers, or a partner under a fixed-scope agreement | One-time, with ongoing effort when new systems are added | Count of systems with no API or export path and the need for manual collection |
| Data owner review time | Business data owners who confirm sensitivity and location | Recurring at least annually, as Safeguard 3.2 requires | How many owners exist, how often data sets change, and whether owners are named in the data management process |
| Evidence upkeep | Compliance or security staff who keep versions, change records and sign-offs current | Recurring | How well the inventory is kept in version-controlled tooling versus spreadsheets |
| Auditor sampling and testing | Independent auditor or assessor, who tests the inventory against the evidence you present | Recurring with each assessment cycle | Scope of the assessment, the number of sensitive data sets sampled, and the quality of linked evidence |
| Completeness checks against the asset inventory | Asset and software inventory owners, as Safeguard 1.1 typically feeds this work | Recurring | Gaps between the asset inventory and data stores, especially shadow SaaS and cloud storage |
| Quote items to request | Your procurement or finance team with the implementation partner | Not applicable | Ask for itemized lines for discovery, build, owner workshops, evidence setup, annual review support and any license fees, each with its assumptions |
Open-source tools that hold data inventory evidence
A data inventory is only useful as evidence if an assessor can see what it said at a given date and who changed it. XWiki is a wiki platform licensed under LGPL-2.1-or-later that keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For Safeguard 3.2, this gives you a dated trail that shows the inventory was reviewed and updated, which is the pattern the assessment specification looks for when it checks whether the inventory is current.
- Change history: Each edit to an inventory page is stored with its author and timestamp, so reviews can be reconstructed.
- Version comparison: Reviewers can see which data sets were added, reclassified or removed between annual reviews.
- Rollback: Incorrect edits can be reverted without losing the record of the error.
- Structured pages: Teams can keep one page per data set with fields for sensitivity, owning asset and location, which makes gaps easier to spot.
- Licence considerations: LGPL-2.1-or-later permits use, but your legal team should confirm obligations if you modify the source and distribute it.
Before relying on version history as evidence, confirm with your platform team that versioning is enabled on the inventory space and that retention of old versions meets your own records policy.
The inventory must be accurate, and that depends on who is allowed to edit it. BookStack is a documentation platform licensed under MIT. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. You can use this to separate the people who maintain the inventory from the people who only read it, and to keep sensitive entries visible only to the teams that need them. This supports the need-to-know thinking behind Safeguard 3.3 without treating the inventory itself as a data store.
- Role-based editing: Restrict edit rights on the inventory book to the data owners and the team that runs the data management process.
- Scoped overrides: Set stricter permissions on a single chapter that lists regulated personal data, while leaving general sections open to read.
- Read access for auditors: Give assessors read-only roles for the period of an engagement and remove them afterwards.
- Account linkage: Tie roles to your identity provider where the platform supports it, so leavers lose access through the same process as other systems.
- Licence considerations: MIT is permissive, but confirm any plugins or themes you add carry compatible terms.
Confirm the exact role configuration in your own installation, because permission inheritance depends on how the shelves and books are structured.
An inventory often has to satisfy more than one framework. CISO Assistant is a compliance platform licensed under AGPL-3.0-only that ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR. It can run audits and compliance assessments against them with automatic mapping between frameworks. For Safeguard 3.2, you can record the inventory as an evidence item and link it to the controls it supports, so one review feeds several assessments. CIS maps this Safeguard to NIST CSF 2.0 ID.AM-07, NIST SP 800-53 Rev. 5 CM-12, PM-5(1) and RA-2, ISO/IEC 27001:2022 Annex A 5.9, SOC 2 C1.1, CC3.2 and CC6.1, and PCI DSS v4.0 requirements 3.2.1, 9.4.2, 9.4.5.1 and 12.5.2. Check these mappings against the current CIS Navigator before you rely on them.
- Evidence linkage: Attach the inventory version and review record to each linked control.
- Assessment tracking: Record gaps, owners and due dates in one place rather than in spreadsheets.
- Framework coverage: Confirm that the framework versions you need are included in your release.
- Licence considerations: AGPL-3.0-only applies network-use obligations to modified versions. Have counsel review this before you customize it or offer it to users.
- Scope limit: The platform manages assessment records. It does not scan storage or identify where sensitive data sits.
Confirm with your assessor which framework mappings they accept as the basis for testing.
None of these tools discovers data. They store, version, restrict and map what your people have recorded. Finding sensitive data across file shares, databases, cloud storage and endpoints is a separate task, handled by discovery and data loss prevention tooling and by structured interviews with data owners. Safeguard 3.13 covers automated DLP, and Safeguard 3.1 defines the sensitivity levels the inventory must follow. Treating the wiki as the inventory is only defensible if the content was built from a real discovery exercise.
- Discovery gap: A well-kept page cannot show data that nobody recorded, so completeness depends on the discovery method.
- Sensitivity rules: The tools do not decide what counts as sensitive. Your data management process must set that.
- Asset linkage: Each entry should name the asset that stores the data, which requires the asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1.
- Review discipline: Annual review is a process requirement that the tools can record but cannot enforce.
- Assessor expectations: Ask your assessor how they will test completeness and which sources they will compare against.
Before you commit to a toolset, confirm with your team how discovery was performed and document that method alongside the inventory.
Where data inventories usually fall short
Safeguard 3.2 is measured on whether a sensitive data inventory exists and stays current, so most failures are about upkeep rather than first drafts. The cards below cover the gaps assessors most often find, each paired with a check the team can run before the review.
Inventory built once, never updated
A spreadsheet produced for a past audit often describes systems that have since been retired, renamed or merged. The Assessment Specification scores Safeguard 3.2 as failing when the inventory has not been updated for more than 12 months, so the date of the last full review is the first thing an assessor checks. Confirm the last review date and who signed it off. Schedule the review on the same calendar as the data management process.
SaaS stores left out
Sensitive data often lives in SaaS collaboration tools, CRM platforms, ticketing systems and analytics services that were adopted by individual teams. These stores sit outside the server and database inventories that many organizations build first. Ask each business unit to list the SaaS applications it uses for customer, employee or financial records, and compare that list against the sensitive data inventory.
Backup stores omitted
Backup repositories, snapshots, replicas and archive tiers hold full copies of production data, often including data that production has since deleted. Teams commonly inventory the primary database and forget the backup copy, which then falls outside retention and disposal rules. Check that every backup target appears as a data location with its own sensitivity label and retention period.
Data owners not named
An inventory entry without an accountable owner cannot be validated, classified or retired when the business changes. Assessors look for a named person or role for each data set, not a team mailbox. Illustrative example: a customer export file with no owner has no one to approve its retention or confirm that it still exists. Assign one owner per data set and record the owner in the inventory.
Inventory detached from the data management process
Safeguard 3.2 requires the inventory to follow the enterprise's data management process, which defines sensitivity levels, handling and retention. When the inventory uses its own labels or ignores those levels, it cannot show that sensitive data is covered at the level the process requires. Compare the inventory's sensitivity values against the process document line by line.
No evidence of yearly review
A review that happened but left no record is hard to prove. Assessors expect dated versions, the reviewer's name and a record of what changed, so the review can be shown to have taken place within the year. Keep the inventory in a system that records version history, and export a dated copy at each review. Keep a signed review record for every annual cycle.
Questions buyers ask about the CIS data inventory
How much does it cost to build a CIS data inventory?
No supplied figure sets a price for this work, and the cost depends almost entirely on scope: how many systems hold sensitive data, how many data owners must be interviewed, and whether the data is mapped manually or with discovery tooling. The organization pays for its own staff time from data owners, IT and the security team, which is usually the largest and most recurring component. A partner is paid for the work it is contracted to do, such as preparing the inventory template, running discovery, and documenting results. Ask for a quote that separates the initial build from the annual review, lists the systems in scope, and states which deliverables are included in a fixed-scope engagement. DeployOpen does not publish prices; a quote follows from the written scope.
How long does the first data inventory take?
The duration depends on how many systems and data stores are in scope, how well the data management process from Safeguard 3.1 is documented, and how quickly data owners respond. CIS does not publish a duration for this Safeguard in the supplied material, so treat any timeline from a vendor or partner as an estimate to be tested against your own environment. A practical first step is to agree the sensitivity levels and the priority systems, then inventory those systems before expanding to lower-risk data. Ask for milestones in the written scope so progress can be measured.
What does the work need from data owners?
Data owners must confirm what sensitive data they hold, where it is stored and processed, who uses it, how long it is kept, and which sensitivity level applies. The CIS Controls Assessment Specification measures how fully data is mapped to sensitivity levels and to the assets that store it, so owners' answers become the core evidence. Expect each owner to review a draft list, correct gaps, and sign off on the entries they are accountable for. Name a single accountable owner for each data set before the work starts, otherwise reviews stall.
Can our team build the data inventory in-house?
Yes, an internal team can build the inventory if it has the authority to request information from data owners and enough time to maintain it. The work is mostly coordination and documentation rather than specialized tooling, so the main risk is that it is treated as a one-time spreadsheet exercise. Whether to use internal staff or an outside partner depends on capacity, familiarity with the systems, and whether the organization needs independent evidence for an assessment. Confirm that staff can keep the inventory current at least once a year, as the Safeguard requires.
What does an implementation partner add to the inventory work?
A partner prepares systems and evidence: it can structure the inventory template, run discovery across systems, map findings to sensitivity levels, document the results, and set up version-controlled records for the review cycle. Partners such as DeployOpen implement and document self-hosted open-source platforms inside the client's own infrastructure, so the inventory can be kept in tools the client controls. The organization still owns its data, its decisions on sensitivity, and its controls. Only an independent auditor or assessor issues reports or certifications, so a partner's work is evidence for an assessment, not the assessment itself.
How does the data inventory differ from the asset and software inventories?
The asset inventory (Safeguard 1.1) lists the devices on the network, and the software inventory (Safeguard 2.1) lists the applications that run on them. The data inventory in Safeguard 3.2 lists the data itself, at minimum all sensitive data, and records where it lives and at what sensitivity level. The CIS Controls Assessment Specification lists Safeguard 1.1 as a prerequisite for measuring Safeguard 3.2 because the asset inventory typically produces data the measurement needs. In practice, the data inventory points back to the device and software records so each sensitive data set can be traced to the systems that hold it.
How does the data inventory connect to the other Control 3 Safeguards?
The inventory is an input to most of the Control 3 Safeguards. Safeguard 3.1 defines the data management process and sensitivity levels that the inventory applies. Safeguard 3.7 turns those levels into classification labels, and Safeguards 3.3, 3.4, 3.5 and 3.7 list Safeguard 3.2 as a prerequisite, along with several others. Retention (3.4), disposal (3.5), data flows (3.8), segmentation (3.12), data loss prevention (3.13) and logging of sensitive data access (3.14) all depend on knowing where sensitive data is. Treat the inventory as the shared record that these Safeguards reference, and review it when any of them changes.
How DeployOpen prepares a data inventory for review
DeployOpen scopes the Safeguard 3.2 work in writing before any tooling is touched. The scope names the business units, data domains, systems and service providers in play, the sensitivity levels that come from the enterprise's own data management process, and the people who own each data set. The enterprise owns the inventory and its sensitivity decisions; DeployOpen plans and builds the self-hosted environment that holds it, and documents how the inventory is kept current. Because the Safeguard sits inside the data management process, the scope also records which sensitivity definitions and review cycle the enterprise has already adopted, so the inventory is not built against undocumented rules.
DeployOpen then implements the self-hosted records inside the client's own cloud accounts, data centers or air-gapped network. A wiki platform such as XWiki can keep each data set entry, its owner and its sensitivity under version control, recording what changed, when and by whom, and allowing comparison and rollback between versions. BookStack can hold the handbook pages with role-based permissions set per shelf, book, chapter or page, so data owners edit their own entries while reviewers only read. Where the enterprise wants framework mapping, CISO Assistant can record the Safeguard against its mapped controls. Confirm with each vendor that the capabilities your assessor needs are present in the version you deploy.
For the review, DeployOpen assembles the evidence package the enterprise's independent auditor or assessor will ask for: the dated inventory export, the approval record for each review cycle, the change history showing sensitive data was reviewed first, and the links to the asset inventory from Safeguard 1.1 that the assessment specification treats as a prerequisite. DeployOpen prepares these systems, controls and evidence, but it does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can issue those. Ask your auditor which evidence format and sampling approach they will accept before the scope is signed.
