What the CIS data management process requires and why it comes first
If your team is preparing for a CIS-aligned review and your data rules live across a wiki page, a ticket queue and a few spreadsheets, Safeguard 3.1 is the place to start. It asks the enterprise to establish and maintain a written data management process. That process should say how sensitive data is identified, who owns each data set, how it must be handled, how long it may be kept and how it must be disposed of. Those rules must tie back to the enterprise's own sensitivity and retention standards, and the process must be reviewed once a year or after a significant change to the enterprise. In CIS Controls v8.1, the Safeguard sits in the Data asset class and the Govern security function, and it applies at all three Implementation Groups, which makes it part of IG1 essential cyber hygiene.
The rest of Control 3 depends on this document. The data inventory in Safeguard 3.2, the retention rules in 3.4, disposal in 3.5, classification in 3.7 and data flow documentation in 3.8 all refer back to sensitivity levels, owners and handling rules that must already be defined. The CIS Controls Assessment Specification reflects this: it lists no prerequisite Safeguards for 3.1, while 3.4, 3.5, 3.7 and 3.8 each list 3.1 as a prerequisite. Assessors will score 3.1 as failing if no process exists. If one exists, they check five elements: data sensitivity, data owners, handling guidance, retention limits by sensitivity and disposal requirements by sensitivity. Confirm this wording against the current specification before you build your checklist.
What usually makes this hard is less the writing than the agreement. Sensitivity levels often differ between legal, finance, engineering and the business units, and no one has been named accountable for a given data set. Retention periods may come from contracts or regulators that nobody has mapped to systems. Procedures sit in the wiki while the approved version sits in a policy repository. A practical first step is to list the data types the enterprise holds, name an owner for each, and ask those owners to confirm the sensitivity label and the retention and disposal rules they can actually enforce. Those decisions, not the template, are what the assessor will test.
Which systems, data, teams and third parties the process must cover
Safeguard 3.1 applies to whatever the organization decides is in scope, so the scoping choices made before drafting the process determine how much review, ownership and evidence follow. The four to six decisions below are the ones that most change the workload, and each should be recorded in the written process before the rest of Control 3 is built on it.
Defining which data counts as sensitive
The process ties handling, retention and disposal to sensitivity levels, so the first decision is which data types fall into those levels. A narrow definition (for example, only regulated personal data) produces fewer categories and less review, but it can leave customer contracts, source code or internal financial forecasts without handling rules. Illustrative: a company that adds one new sensitivity tier for contractual data adds a retention rule and a disposal method for that tier. Check that the definition matches the organization's own legal and contractual obligations.
Naming business units and data owners
Each sensitivity category needs a named owner who can decide how the data is used, shared and retired. The more business units hold sensitive data, the more owners must review and approve the process, and the longer each annual review takes. Confirm that every owner has authority to accept retention limits and disposal requirements on behalf of their unit, not only a technical contact. Record the sign-off path in writing, since an assessor will look for owners by name, not by function alone.
Mapping systems that hold in-scope data
Every system that stores or processes sensitive data must be covered by the handling and disposal rules, which means the inventory must reach beyond on-premises servers. Include databases, file shares, backups, endpoints, collaboration tools and SaaS applications, plus cloud object storage. Each additional system adds a row to the data inventory and a disposal method to confirm. Ask the team to search for copies, exports and backups, because an incomplete system list leaves data outside the process.
Covering cloud and SaaS storage
Cloud storage and SaaS platforms often hold sensitive data with settings controlled by someone other than the central IT team, such as a department administrator or a vendor default. Decide whether these locations fall under the same retention limits and disposal steps as internal systems, and who can change those settings. Illustrative: a shared drive created by a sales team may keep customer exports for years unless retention is set at the tenant level. Confirm the retention and deletion controls each provider offers before the process promises them.
Identifying service providers that handle data
When a provider stores, processes or can access sensitive data, the retention and disposal rules must reach into that provider's contract and offboarding terms. The number of providers and the sensitivity of their data determine how many contracts need updated handling language and how often their disposal evidence must be requested. Ask each provider how it deletes data, how long backups persist and whether it will certify disposal. Data flows to these providers are also documented under Safeguard 3.8, so the two lists should match.
Setting the review trigger for changes
The process must be reviewed once a year and after significant enterprise changes such as mergers, new cloud regions or a new SaaS platform for sensitive data. Decide in advance what counts as significant, because that definition determines how often unplanned reviews happen. A short written trigger list, such as new sensitive data type, new processor or new jurisdiction, lets the team show when reviews were prompted and what changed.
How an assessor tests the data management process
This table walks through the test approach the CIS Controls Assessment Specification describes for Safeguard 3.1, from confirming that a written process exists to checking each completeness element. Read it as a sequence: a missing process fails the test outright, and a partial process usually fails on one of the five elements. The assessor issues the result, and no prerequisite Safeguards apply before testing 3.1.
| Test step | What the assessor asks for | Evidence requested | Common finding |
|---|---|---|---|
| 1. Confirm a written process exists | Is there a documented data management process, approved and in use? | The current written process, its approval record and its version history | Practices described verbally or spread across unrelated policies, with no single document |
| 2. Check data sensitivity | Does the process define sensitivity levels for enterprise data? | Sensitivity definitions and the categories of data each level covers | Levels named but not defined, or no statement of which data falls into which level |
| 3. Check data owners | Does the process name who owns each category of data and their responsibilities? | Owner assignments by data category and the role descriptions that confer ownership | Owners named as IT teams rather than accountable business roles |
| 4. Check handling guidance | Does the process explain how data at each sensitivity level must be stored, shared, labeled and accessed? | Handling rules by sensitivity level, linked to the systems where that data lives | Handling rules that are generic and do not differ by sensitivity |
| 5. Check retention limits by sensitivity | Does the process set how long each sensitivity level may be kept? | Retention schedule by data category and sensitivity, with the basis for each period | Retention stated for some data types only, or with no maximum period |
| 6. Check disposal requirements by sensitivity | Does the process state how each sensitivity level must be disposed of at end of life? | Disposal rules by sensitivity and examples of disposal records from recent cycles | Disposal rules that stop at deletion without covering backups, removable media or service providers |
| 7. Check review cadence | Is the process reviewed once a year and after significant enterprise changes? | Review records with dates, reviewers and the changes made | Annual review claimed but no dated record of it, or no review after a major change |
| 8. Record the result | The assessor determines whether the Safeguard passes or fails and states the basis. | Assessor's working papers and the test result. The organization owns its controls; only the independent assessor issues the result. | Teams treating an internal self-check as the assessor's conclusion |
How to build the process in the order the rest of Control 3 needs it
The sequence turns Safeguard 3.1 into a single approved document that defines sensitivity, ownership, handling, retention and disposal, so the later Control 3 Safeguards have a stable base to build on. Each step closes with a named output you can check before moving on.
Agree sensitivity levels with business and legal owners
Start by defining a small set of sensitivity levels that describe what the enterprise holds, such as public, internal, confidential and restricted. Run this with business unit leads, legal counsel and the privacy function, because they know which records carry contractual, regulatory or personal data obligations. The output is a short, signed-off level definition with a plain-language test for each level. You know it is done when two people from different departments can classify the same sample record and reach the same level.
Assign a named owner to each data category
Name an accountable owner for each major category of data, normally a business leader rather than an IT administrator. The owner decides who may use the data, approves exceptions and answers for the data's sensitivity during reviews. Record the owner alongside the category so that the owner can later confirm the data inventory under Safeguard 3.2. The output is an ownership register with one owner per category and a deputy named for absence cover. It is done when every category in scope has exactly one accountable owner.
Write handling rules for each sensitivity level
For each level, write the rules that govern everyday handling: where data may be stored, who may share it, how it may leave the enterprise, and which encryption and access expectations apply. Keep the rules short enough that engineers and staff will read them, and link to the technical standards that enforce them where those standards already exist. The output is a handling table with one row per level. It is done when a reviewer can point to a rule for every sensitivity level and every common storage or sharing location.
Set retention limits and disposal requirements per level
For each sensitivity level, set the period during which data may be kept and the minimum period it must be kept, citing the legal or contractual source where one applies. Then define the disposal method expected at the end of that period, matched to the level. Safeguards 3.4 and 3.5 turn these rules into enforced retention and disposal, so the timelines must be explicit rather than implied. The output is a retention and disposal schedule with a source note for each entry. It is done when every level has both a retention rule and a disposal method. Confirm any legal retention periods with counsel, since this guide does not supply them.
Approve and publish the data management process
Combine the sensitivity levels, owners, handling rules and retention and disposal schedule into one written process document. Obtain approval from the executive or governance body that owns information risk, then publish it where staff and system owners can find it. Record the version, the approver, the approval date and the review owner at the top of the document. The output is an approved, version-controlled document. It is done when the approval is on record and the document is linked from the policy set that governs data handling.
Set the annual and change-triggered review
Schedule a review of the process at least once a year, and open an additional review when a significant enterprise change occurs, such as a new product handling sensitive data, a merger, a new service provider or a change in applicable law. Assign the review owner and record the trigger criteria in the document itself. The output is a review calendar and a short list of trigger events. It is done when the next review date is set and the trigger list is part of the approved document.
Confirm the dependent Safeguards can draw on the output
Before the rest of Control 3 begins, check that the approved process gives each dependent Safeguard what it needs. Safeguard 3.4 needs the retention limits, Safeguard 3.5 needs the disposal requirements, Safeguard 3.7 needs the sensitivity levels to become labels, and Safeguard 3.8 needs the owners and handling rules to document data flows. The output is a short cross-reference that maps each dependent Safeguard to the section of the process it uses. It is done when a reviewer can trace each dependent Safeguard to a named section without gaps.
Evidence that shows the process exists, is approved and is current
Safeguard 3.1 is judged on evidence, not intent. The six artifacts below show that a data management process exists, that someone with authority approved it, that owners and handling rules are defined, and that the process has been kept current. Each one needs an owner and a review date so it still holds up when the assessor arrives.
Approved data management process document
This is the written process itself, covering how sensitive data is identified, who owns it, how it is handled, how long it may be kept and how it is disposed of. Check that the document names an accountable approver, carries a version number and links to the sensitivity and retention standards it depends on. An assessor will start here, so a document that exists only as a draft or in an individual's notes will not satisfy the Safeguard.
Sensitivity definitions
The sensitivity levels are the foundation that the other elements rely on. Each level should have a plain-language definition, examples of data that falls into it and the minimum handling expectations attached to it. Keep the definitions in the same version-controlled location as the process so that a change to a level is traceable. Assessors check that sensitivity is defined at all, so an undefined or single-label scheme is a common gap.
Data owner register
This register lists each data set or system of record, the named business owner accountable for it and the date the owner last confirmed the entry. Ownership must be a person or role with decision authority, not a shared mailbox or the IT help desk. Review it when staff change roles, because a stale register is one of the most frequent findings when the process is tested against the five required elements.
Handling and disposal standards
These standards translate each sensitivity level into rules for storage, sharing, transmission and destruction, including the retention limit for each class. Write them so an engineer or records administrator can follow them without interpretation. Confirm that the disposal requirements state a method for each level. Safeguards 3.4 and 3.5 depend on these rules, so gaps here carry forward into those assessments.
Approval and review log
The log records each approval of the process, each annual review and the reviewer's decision, with dates and names. Safeguard 3.1 expects review once a year, so an assessor will look for an entry within the last twelve months. If the process has never been formally approved, the log will show that, and the gap is easier to close before the assessment than during it.
Change records for significant enterprise changes
Safeguard 3.1 requires review after significant enterprise changes as well as annually. Keep records of events that triggered an update, such as a merger, a new cloud region, a new regulated product line or a new service provider holding sensitive data, along with what changed in the process and who approved it. Assessors use these records to test whether the process responds to change or only to the calendar.
Self-hosted open-source tools that keep the process versioned and current
XWiki is a wiki platform licensed under LGPL-2.1-or-later that you can host in your own infrastructure. Its main value for Safeguard 3.1 is version history: the data management process is a document that changes over time, and an assessor will want to see what the current version says, what the previous version said and who approved the change. Because XWiki keeps every change under version control, the page history becomes part of the evidence trail rather than a separate filing task.
- Change history: Each edit records what changed, when and by whom, so the history of sensitivity levels and retention limits can be shown on request.
- Compare and rollback: Reviewers can compare any two versions and restore an earlier one if a change was made in error.
- Review record: A dated annual review can be captured as a new version with a short change note.
- Access to the page: Rights are set on the wiki, so confirm they match who should edit the process.
- Export for auditors: Confirm how history and attachments can be exported in your environment before an assessment.
Confirm with your platform team that the LGPL-2.1-or-later terms fit how you plan to modify or distribute the software, and that backups of the wiki database and attachments are included in your recovery scope.
BookStack is a documentation platform licensed under MIT that organizes content into shelves, books, chapters and pages. For Safeguard 3.1, its role model matters more than its layout. A data management process usually has a small set of editors, a wider group of readers and one or two approvers, and BookStack lets you give those groups different abilities. Permissions come from the roles assigned to each user and can be overridden per role at the shelf, book, chapter or page level, so the approved process can be locked down while working drafts stay with the owners who write them.
- Role-based editing: Assign editing rights to data owners and the team that maintains the process, and read-only access to everyone else.
- Scoped overrides: Restrict a sensitive chapter, such as retention limits for regulated data, to fewer users than the rest of the book.
- Draft and approved separation: Keep drafts in a book that only editors can see, and publish approved versions to a book that the wider organization can read.
- Access evidence: Role assignments and overrides can be exported or screenshotted to show who could change the process at a given date.
- Limited history: Confirm how far page revisions go back in your version and whether they meet your retention needs, since version depth may be less detailed than a dedicated version control model.
Confirm that the MIT license terms fit your use, and test the permission model with a sample user from each role before you rely on it for approval evidence.
CISO Assistant is a governance, risk and compliance platform licensed under AGPL-3.0-only. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it can run audits and assessments against them with automatic mapping between frameworks. For Safeguard 3.1, it does not hold the policy text. Its job is to connect the documented process to the frameworks that cite data handling, retention and disposal, and to track the assessments that test them. Any mapping it shows should be checked against the framework owner's own material before it appears in an audit file.
- Framework tracking: Record which frameworks your data management process is expected to satisfy and link the requirements to the process.
- Assessment records: Track audits and assessments, findings and owners, giving the review cycle a visible home.
- Automatic mapping: Use the built-in mappings to see related requirements across frameworks, then validate them against the source standards.
- Evidence linking: Attach or reference the approved process version, review record and disposal records to the requirements they support.
- Deployment scope: Confirm which frameworks and mappings are included in the version you deploy, since content and coverage can change between releases.
AGPL-3.0-only has network-use obligations if you modify the software and make it available to users, so have counsel review the terms before you customize it. Confirm the fit with your compliance lead, because the tool records and organizes evidence but does not decide whether your controls are adequate.
What meeting Safeguard 3.1 costs in money and effort
This table breaks down the cost components of building and keeping a data management process under Safeguard 3.1, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, because no prices or durations are supplied for this Safeguard and the real figures depend on the size and structure of your enterprise. The main takeaway is that open-source software can remove license spend, but the largest share of effort is staff time from owners, legal and reviewers.
| Cost component | One-time or recurring | What drives it up or down | How to keep it down |
|---|---|---|---|
| Internal drafting time | One-time, then recurring on revision | Number of data types, number of business units and whether any sensitivity standard already exists | Start from an existing policy or CIS policy templates and limit the first version to the five elements the assessment checks |
| Legal and data owner review | One-time, then recurring at each annual review | How many owners must sign off, whether retention limits must match statutory periods and how many jurisdictions apply | Name owners per data category in advance and agree a standing review path with legal for routine changes |
| Tooling or licenses | Recurring if commercial, often none for open source | Choice of commercial document management or GRC platform versus self-hosted wiki or GRC tools with version history | Use self-hosted open-source tools for the document and version history, and confirm each license terms before adoption |
| External review | Optional, one-time or periodic | Whether an independent party reviews the process before an assessment and how much scope that review covers | Ask for a scoped review of the written process only, not a full program assessment |
| Annual upkeep | Recurring | Frequency of significant enterprise changes such as mergers, new cloud regions or new data products, which trigger reviews beyond the annual cycle | Tie reviews to change management so updates happen when systems change instead of as ad hoc projects |
| Auditor sampling and evidence requests | Recurring at each assessment | Number of versions the assessor asks to see, how quickly the team can show approval history and whether dates are traceable | Keep approval records, dated revisions and sign-off evidence in one place from the first version onward |
Who owns the process, who helps write it, and who tests it
Your organization owns the data management process. Accountability for Safeguard 3.1 sits with the people who decide what counts as sensitive, who owns each data set and how long records may be kept. Those decisions depend on business context, legal obligations and risk appetite, which an outside party cannot make for you. The CIS Controls Assessment Specification checks whether a documented process exists and covers five elements, so your team must be able to show that the approvers, owners and reviewers named in the document actually hold those roles.
- Executive approval: A named executive or governance body approves the process and the sensitivity and retention standards it references.
- Data owners: Business leads are named for each major data set and accept responsibility for handling and disposal.
- Annual review: Someone is accountable for reviewing the process once a year and after significant enterprise changes, and the review is recorded.
- Legal and privacy input: Counsel or the privacy function confirms retention limits that come from statute or contract.
- Operational knowledge: IT and application teams confirm how data is actually stored, handled and deleted, so the document describes real practice.
Check that each role named in the process has a person behind it, and that the people who approve the document are not the same people who draft it without review.
An implementation partner such as DeployOpen can help prepare the documentation and the systems that hold it. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it prepares controls and evidence for compliance assessments. It does not decide your sensitivity levels, set your retention periods or issue any assessment result. The partner works from decisions your organization has already made or is making, and its scope and deliverables are agreed in writing before work starts.
- Facilitation: Workshops that gather sensitivity, ownership and retention decisions from the business, recorded for approval.
- Drafting support: First drafts of the process document, mapped to the five elements the assessment specification checks, for your reviewers to edit.
- Tooling setup: Configuring a wiki or document platform with version history and role-based permissions so approved versions and review dates are visible.
- Evidence preparation: Assembling approval records, review logs and version histories in a form an assessor can sample.
- Gap review: Comparing the drafted process against the assessment specification and listing what is missing before the assessor arrives.
Ask any partner to state in the statement of work which artifacts it will produce and which decisions remain with your staff.
An independent auditor, assessor or certification body is the only party that tests Safeguard 3.1 and issues any report or result. The auditor is not part of the team that wrote the process, and it must remain independent of the partner that helped prepare evidence. Where a customer or regulator asks for CIS Controls evidence, the auditor's scope determines which Safeguards and Implementation Groups are tested. Any formal accreditation or certification of a CIS Controls service provider is a separate matter and should be confirmed directly with the body concerned.
- Test design: The auditor selects the Safeguards, Implementation Groups and systems in scope and decides the sample.
- Document review: The auditor reads the process for the five elements and checks it was approved and reviewed on schedule.
- Interviews: Data owners and approvers are asked whether the process reflects how they work.
- Sampling: The auditor selects data sets and checks their recorded owner, handling rule and retention limit against the process.
- Reporting: Only the auditor issues the findings, opinion or certificate, and your organization decides how to share them.
Confirm whether the auditor you engage is accredited or recognized for the framework your customers require, and confirm that the same firm is not designing the controls it later tests.
Why data management processes fail review and how to close each gap
Assessors reviewing Safeguard 3.1 rarely reject a process for being badly written. They reject it because it is missing elements, is not owned, or is not used. The gaps below are the ones that most often separate a document from a working process, and each has a practical fix that can be checked against the five elements the assessment specification looks for.
Process exists only in someone's head
If the handling rules for sensitive data are known to a few senior staff but never written down, the Safeguard fails outright, because the assessment specification scores it as failing when no data management process exists. Write the process as a controlled document covering sensitivity, ownership, handling, retention and disposal, then have someone outside the author confirm it reads as complete. Ask for the approved version and its approval date during review.
No named data owners
A process that says data has owners but does not name them leaves nobody accountable for classification, access decisions or disposal. Assign an owner for each major data set or system by role, record the name and deputy, and state what the owner must approve. An assessor will look for owners in the document itself, not in an org chart that may be out of date.
Sensitivity levels without handling rules
Defining levels such as Public, Internal and Sensitive is only half the job. Each level needs stated rules for storage, sharing, transmission and printing, so that a person handling a record knows what is allowed. Check that every sensitivity level in the document has a matching handling entry and that no level is defined but left without guidance.
Retention limits that ignore legal and contract needs
Retention periods set by IT convenience often conflict with statutory minimums, contractual obligations or litigation holds. Build each retention limit from the legal, regulatory and contractual requirements that apply to each data type, and record the source of each figure. Confirm the limits with legal counsel, since the assessment checks that retention and disposal rules exist per sensitivity level.
No review record
Safeguard 3.1 expects the process to be reviewed once a year or after significant enterprise changes, such as a merger, a new cloud platform or a new regulated product. A missing review log is an easy finding to raise. Keep a short change history showing the reviewer, the date, the changes made and the trigger for each review. A wiki with version history, such as XWiki, can hold this record directly.
Process never reaches data holders
A correct policy that sits in a shared drive does not change how staff store, share or delete data. Publish the process where the teams holding data will read it, tie each sensitivity level to the systems they use, and require acknowledgement from data owners. Ask for evidence that owners were briefed and that the handling rules appear in the places people work, such as system onboarding checklists.
How long, how much effort and what to expect when preparing this process
Can we write a data management process ourselves without a consultant?
Yes, in most organizations the process is written in-house, because it describes your own data, owners and retention obligations, which only you can state accurately. Safeguard 3.1 needs a written process that covers data sensitivity, data owners, handling guidance, retention limits by sensitivity and disposal requirements by sensitivity. The work is mostly coordination: a security or compliance lead drafts the document, data owners confirm what they hold, and legal confirms retention obligations. Outside help is most useful when the data estate is large, spans several jurisdictions, or nobody internally has time to drive the review. Whoever writes it, the organization owns the content and its approval.
What does the process need from legal, privacy and data owners?
Legal and privacy teams supply the retention and disposal obligations that the process must reflect, while data owners supply the knowledge of what each dataset contains and how it is used. Legal typically confirms statutory and contractual retention periods and any hold requirements. Privacy confirms how personal data is classified and what disposal rules apply. Data owners identify the datasets they are accountable for, describe handling needs, and agree to review them. Each group's sign-off should be recorded, because an assessor will look for named owners and an approval trail, not just a document.
How long does it take to prepare the process?
The duration depends on scope, and no reliable figure applies across organizations. The main variables are how many data types and business units are in scope, how many data owners must be consulted, how many legal retention rules apply, and whether sensitivity levels already exist in a classification policy. A single-product company with clear ownership can move quickly, while a multinational with fragmented records will spend most of its time on consultation and agreement. Ask any partner or internal team for a timeline tied to a written scope, with the number of owners, systems and jurisdictions it assumes.
What drives the cost of preparing this process?
Cost is mostly internal staff time plus any external support, and it rises with scope. The main drivers are the number of data categories, the number of data owners to interview, the amount of legal review, and whether existing policies can be reused or must be rebuilt. Tooling costs are usually small compared with people time, though a wiki or document system with version history may be needed. Recurring costs come from the annual review and from updates after significant changes such as new products, acquisitions or new regulations. When requesting a quote, ask what is one-time work, what is recurring, and which parts are performed by your staff.
Will an assessor accept a template for the data management process?
A template is a reasonable starting point, but an assessor will test whether the document reflects your environment. The CIS Controls Assessment Specification checks for five elements: data sensitivity, data owners, handling guidance, retention limits by sensitivity and disposal requirements by sensitivity. A generic template that lists these headings without naming your data types, owners or retention periods will not show that the process is implemented. Confirm with your independent assessor or auditor how they will test it, and treat any template as a draft that you must fill with your own content and approvals.
How often must the data management process be reviewed?
Safeguard 3.1 calls for review once a year, and also after significant enterprise changes. Annual review keeps sensitivity levels, owners and retention rules current. Significant changes that should trigger an earlier review include new products that handle personal or regulated data, mergers, changes in law, new cloud regions or a move to a new service provider. Record each review with its date, the reviewer and any changes, because the review history is part of the evidence an assessor will request.
What does an implementation partner do and what does it not provide?
An implementation partner prepares the systems, documents and evidence that support the process, but it does not own the process or issue any compliance report. DeployOpen, for example, can plan and document how an open-source wiki or document system will hold the data management process with version history and role-based permissions, and can set up the review workflow under a fixed-scope written agreement. The organization still decides its sensitivity levels, owners and retention periods. Only an independent auditor, assessor or certification body issues reports or certificates. Ask for the deliverables, the owner responsibilities and the review cadence to be written into the scope before work starts.
How DeployOpen scopes and prepares the Safeguard 3.1 process
DeployOpen helps organizations put a written data management process in place for Safeguard 3.1 and keep it current. The organization owns its sensitivity levels, data owners, retention limits and disposal rules, and DeployOpen prepares the documentation, the platform that hosts it and the evidence that shows the process is reviewed. Independent assessors, not DeployOpen, decide whether the Safeguard is met.
How we scope
- Agree in writing which business units, data types and systems the data management process will cover.
- Confirm which sensitivity levels, data owners and retention standards the organization already has.
- Define the annual review cycle and the triggers for review after significant enterprise changes.
How we build
- Draft the process document with sections for sensitivity, ownership, handling, retention limits and disposal.
- Host the documentation in a self-hosted wiki inside the client's own infrastructure, such as XWiki or BookStack.
- Configure role-based permissions so owners can edit their sections while approvers control publication.
How we hand over
- Deliver the approved process document with version history showing each change, date and author.
- Provide a review record template so the annual review and change-driven reviews leave dated evidence.
- Document who owns each section and where the approved version is stored for assessors to inspect.
How we support
- Offer ongoing support and periodic review as a retainer after the fixed-scope engagement ends.
- Help the organization update the process when sensitivity levels, retention standards or systems change.
- Prepare evidence packages for the independent assessor, while the organization retains control of its own controls.
