Safeguard 3.4 Enforce data retention

Safeguard 3.4 enforce data retention: what the requirement asks

Safeguard 3.4 requires that data be retained according to the documented data management process, with both minimum and maximum retention timelines. If you are a compliance lead or engineer, the practical question is how you show that data is kept for as long as it must be and removed when its period ends. The Safeguard sits in the Data asset class and the Protect security function, and it applies from IG1, so it is part of the essential cyber hygiene baseline that every enterprise is expected to meet. The CIS Controls do not replace regulatory retention obligations. Where a statute or sector rule sets a required keeping period, your retention schedule must reflect that rule, and you should confirm the specific periods with your legal and compliance owners rather than take them from the Controls.

The risk runs in both directions. Data kept longer than it needs to be widens the impact of a breach, because every stale record is something an attacker can take and something you must later account for in an incident or a data subject request. Data deleted too early can break legal holds, financial record obligations, audit trails and ordinary business needs, and it can leave you unable to answer a question about a past transaction. Retention is hard mostly because rules are written in a policy document but not applied system by system. A schedule may say that customer support tickets are kept for a set period, while the ticketing platform, its backups, its exports and the data warehouse copy each follow their own, undocumented behavior.

For this Safeguard, assessors look for the link between the policy and the systems that hold data. Start by confirming that your data management process (Safeguard 3.1) states a minimum and a maximum timeline for each sensitivity type, and that your data inventory (Safeguard 3.2) shows where each type lives. Then check, for each system, whether retention is enforced by configuration, scheduled jobs or a documented manual step, and keep the evidence of the last run. Ask your team to confirm which backups and archives hold expired data and how their retention is set, since these copies are the most common gap. Open-source platforms can help here: a wiki or documentation tool with version history can record when a retention rule changed and who approved it, and a backup tool such as Bareos can keep a catalog of what each job holds, which lets you show how long copies persist.

Which data, systems and third parties fall under retention rules

Retention rules only work when they are applied to every place a sensitive data type lives, including copies the team forgets about. The cards below cover the scoping decisions that change how many rules and systems an assessor will check. Safeguards 3.1 and 3.2 come first: the data management process defines the sensitivity types, and the data inventory shows where retained data actually sits.

Sensitivity types from the process

Start with the sensitivity types defined in the data management process under Safeguard 3.1. Each type that carries its own minimum and maximum retention period becomes a separate rule, so a scheme with five types produces five rules to test rather than one blanket period. Check that every type in the process has a retention period written against it, and that no type is left with an undefined window. Ask who approved each period and when it was last reviewed.

Data inventory as the locator

The data inventory under Safeguard 3.2 tells you where retained data sits, and it is the prerequisite that makes the rest of this scope possible. Without it, retention rules apply only to the systems people remember. Each inventory entry tied to a sensitivity type adds the systems that must be checked for that type. Confirm that the inventory records the system, owner and sensitivity for each data set before you count the rules.

Databases and file shares

Production databases and file shares usually hold the largest volume of retained records, and they are where deletion jobs most often fail silently. Each database schema or share that holds a sensitivity type needs its own deletion or archival job, and the job must run against the live copy. Check that the job logs what it removed, how many records it touched and whether it has run on schedule. Ask the system owner for the last successful run.

SaaS and cloud storage

Software-as-a-service tools and cloud object storage often keep data under the vendor's default retention settings, which may not match your documented periods. Each SaaS platform that holds an in-scope sensitivity type needs its retention setting recorded and compared against the process. Confirm whether the vendor deletes data on your instruction, how long deleted items remain recoverable, and whether the setting is visible to your administrators. Record the answers in the inventory entry for that platform.

Backups and archives

Backups and archives create copies that outlive the source record, so a deletion in production does not remove the data from backup sets. Decide whether backups are in scope for the maximum period, and if so, define how long backup sets persist and how expired sets are removed. Archives often hold data under a separate, longer minimum period set by law or contract. Each backup set and archive tier needs its own rule, and you should ask who approves exceptions.

Logs and endpoints

Logs and endpoint devices hold sensitive data in less obvious places, such as application logs that record personal identifiers or laptops that cache files. Log retention is governed by its own requirements in Control 8, so check that the sensitivity rule and the log rule do not conflict. Endpoint copies need a rule for when local files expire and how devices are wiped at end of life. Confirm which log sources and device groups carry in-scope data before you set their periods.

Data held by service providers

Service providers that store or process your data hold copies that your own deletion jobs cannot reach. Each provider handling an in-scope sensitivity type needs a contractual retention period, a deletion commitment at contract end and evidence that the deletion happened. Check the provider's data flow documentation under Safeguard 3.8 to identify which providers hold which data. Ask for written confirmation of retention settings and deletion timelines before the contract is signed.

Why retention needs both a minimum and a maximum timeline

A retention rule for Safeguard 3.4 has two sides, and the documented data management process must set both. The maximum timeline limits exposure: data that no longer serves a purpose should be disposed of, so a breach, an over-broad access grant or a discovery request reaches less material. The minimum timeline protects records the business, a contract or a law requires you to keep, such as financial, clinical or audit records. A rule that only sets a maximum will delete records you are obliged to hold. A rule that only sets a minimum will keep data indefinitely, which is the exposure the Safeguard is meant to remove. Either one-sided rule fails the requirement, because the assessor looks for a timeline that can be applied in both directions.

Consider an illustrative example. A company decides that payment dispute records must be held for a minimum period set by its legal and finance teams, then deleted at a fixed point afterward. The retention entry for that record type should name the trigger that starts the clock (for example, case closure rather than creation), the minimum hold, the maximum, the owner who approves exceptions, and the disposal method that Safeguard 3.5 will apply. Ask your legal counsel to confirm the minimum periods for each jurisdiction and sector you operate in. Those periods are not set by CIS, and the Safeguard does not supply them.

CIS's Navigator links Safeguard 3.4 to NIST SP 800-53 Rev. 5 AU-11 and SI-12, to ISO/IEC 27001:2022 Annex A 5.33, and to PCI DSS v4.0 requirement 3.2.1. These links are mappings made by CIS, not statements that the requirements are equivalent. Each control has its own scope and wording, so check every mapping against the CIS Critical Security Controls Navigator entry for the current version before you cite it in an audit file. Then confirm with your assessor and legal team which of those obligations apply to your environment and which minimum periods they impose.

How an assessor checks retention rules per sensitivity type

This table shows how an assessor tests Safeguard 3.4 against the CIS Controls Assessment Specification for v8.1, grouped by the two metrics it combines: completeness of policy and enforcement of retention policy. Read each row as a test question, the evidence the assessor will ask for, and the gap that most often causes a finding. The main takeaway is that a retention schedule alone does not pass; the assessor follows each sensitivity type into the systems and backups where the data actually lives.

Measure area	What the assessor tests	Evidence requested	Common finding
Completeness of policy: retention periods	Whether the documented data management process sets retention for each sensitivity type, with both a minimum and a maximum timeline	Retention schedule approved under the data management process (Safeguard 3.1), listing each sensitivity type and its minimum and maximum periods	Rules that set a minimum but no maximum, or a single period for all data regardless of sensitivity
Completeness of policy: scope and ownership	Whether every data type in the data inventory (Safeguard 3.2) maps to a retention rule and a named owner	Mapping between the data inventory and the retention schedule, with owner sign-off and the review date	Inventory entries with no retention rule, or rules whose owner has left the organization
Completeness of policy: legal and contractual exceptions	Whether documented exceptions, such as legal holds or contract terms, are justified, approved and time-limited	Exception register with the reason, approver, scope and end date for each exception	Holds that never expire, or exceptions recorded informally in tickets or email
Enforcement of retention policy: system configuration	Whether retention is set in each system that stores the sensitive data, such as databases, file shares, SaaS tools and document stores	Configuration exports or screenshots showing retention settings, lifecycle rules or scheduled purge jobs for each in-scope system	Retention applied to only some systems, typically the primary database, while file shares, exports and SaaS tools have no rule
Enforcement of retention policy: deletion operation	Whether data is actually removed when its maximum period passes, and whether the deletion is recorded	Deletion or purge job logs, counts of records removed against the rule, and samples of records that should have been deleted	Purge jobs that run but fail silently, or logs that show jobs ran without showing what was removed
Enforcement of retention policy: backups and copies	Whether backups, replicas, archives and test copies follow the same maximum period as the source data	Backup retention settings and rotation schedules for each backup set, with restore-point ages compared to the retention rule	Backups outliving the rule, so deleted sensitive records can still be restored months or years later
Enforcement of retention policy: sample testing	Whether records selected by the assessor from each sensitivity type match the documented period	Assessor-selected sample of records, with creation dates and current status, reviewed against the schedule	Records past their maximum period that remain accessible, often in older exports, logs or shadow copies

How to implement retention rules from policy to enforcement

This sequence turns the retention limits in your data management process into rules that specific systems apply automatically, and it leaves a record that shows each rule was set, applied and reviewed. Each step produces an artifact an assessor can sample.

Confirm sensitivity types from the data management process
Start from the sensitivity categories defined in your Safeguard 3.1 data management process, since retention rules attach to those categories and not to individual files. The data management owner confirms that every category in use has a name, a definition and an owner, and that no category is missing for data the enterprise actually holds. Done means a short, approved list of sensitivity types that the rest of the sequence can reference by name.
Set minimum and maximum timelines per type
Legal, compliance and business owners set a minimum retention period and a maximum retention period for each sensitivity type. The timelines come from your own legal and business analysis of statutory duties, contractual obligations and operational need, so this document should record the source of each figure rather than borrowing a generic value. Done means a retention schedule that states both limits, the basis for each, and the approver, with a review date set in the data management process.
Map each sensitivity type to systems in the data inventory
Using the data inventory built under Safeguard 3.2, identify every system, repository and backup location that holds each sensitivity type. Record which system is the authoritative copy and which copies are derived, replicated or cached, because each copy needs a rule. Done means a system-to-rule mapping that names each system, its sensitivity types, the applicable retention schedule entry and the person accountable for it. Gaps in the mapping usually point to shadow data stores that the inventory has not yet found.
Configure deletion or archival for each system
For each mapped system, the platform or application owner configures how data reaches the end of its retention period: deletion, anonymization, or movement to an archive with its own controlled access and expiry. Platform teams usually implement this with native lifecycle features, scheduled scripts or database jobs, and the configuration choice depends on what each system can prove about what it removed. Done means a documented configuration per system that matches the schedule, reviewed by the owner and the data management lead.
Test retention jobs before relying on them
Run each deletion or archival job against a non-production copy or a controlled test dataset, then confirm that records past the maximum timeline are removed and records inside the minimum timeline are kept. Include backups in the test, since data removed from production can persist in backup sets unless the backup retention is aligned. Done means test results showing expected outcomes, with any defects logged, fixed and retested.
Schedule and log retention jobs in production
Schedule each job in production with a named owner, and configure the job to write a log entry recording what ran, when, the scope and the result. The logs are the primary evidence an assessor samples when testing whether retention is enforced, so they should be retained and protected under your audit log management practices. Done means a job register listing every scheduled task, its owner and its most recent successful run, with failed runs flagged for follow-up.
Record and review retention exceptions
Some data must be kept beyond its maximum timeline, for example under a legal hold, or deleted early because a request or contract requires it. Record each exception in a register with the reason, the approver, the affected data, the expiry or review date and the compensating controls that apply while the exception runs. Done means an exception register that the data management owner reviews on the schedule set in the process, with each expired exception either closed or re-approved.

Evidence that shows retention is enforced

Retention is only credible when a written rule, a system that applies it and a record of what happened can be shown together. The cards below cover the artifacts that connect the documented data management process to real deletion and archival behavior, and each one should state both the minimum and the maximum side of every rule.

Approved retention schedule per sensitivity type

This is the written schedule that sets, for each sensitivity type, how long data must be kept (the minimum) and when it must be removed or archived (the maximum). It derives from the data management process under Safeguard 3.1 and should name an owner, a legal or business basis and a review date for each row. An assessor checks that every sensitive data type in the data inventory has a row, that no row is missing a maximum, and that the schedule was approved by someone accountable. Keep it current by tying each change to a dated approval.

System-to-rule mapping from the data inventory

This mapping ties each system, database, file share and SaaS tenant holding data to the retention rule that governs it. It is built from the data inventory under Safeguard 3.2, so gaps appear when a system holds data that no rule covers. Assessors use it to test completeness: they pick systems from the inventory and ask which rule applies and where it is enforced. Refresh it whenever a system is added, renamed or retired, and record the date of the last reconciliation.

Enforcement configuration and job definitions

These are the settings and scheduled jobs that actually apply each rule, such as database retention jobs, object storage lifecycle policies, backup expiry settings and mailbox or document-management retention policies. Export or screenshot the configuration with its change history so an assessor can see the rule as implemented, not only as described. Check that each job covers both the minimum hold, which blocks early deletion, and the maximum expiry. Store configuration in version control where the platform allows it, and rerun a review after every platform upgrade.

Deletion and archival logs with timestamps

Logs of deletion, archival and expiry runs prove that enforcement happened, when it happened and to which records. Each entry should identify the rule applied, the data set or record count, the operator or service account that ran the job and the outcome, including failures. Assessors sample these logs to confirm that data past its maximum period was removed and that legal holds prevented removal where they applied. Retain the logs themselves for a defined period and protect them from edit, since an editable log is weak evidence.

Exception approvals and legal holds

Exceptions record cases where data is kept beyond its maximum period or deleted before its minimum, typically for litigation, regulatory investigations or an open incident. Each exception needs a stated reason, an approver outside the team that benefits from keeping the data, a scope and an expiry or review date. Assessors look for exceptions that never close, because a long-running exception often means the rule itself is wrong. Keep a register and review it on the same cycle as the schedule.

Periodic review records

Review records show that the retention schedule, the system mapping and the enforcement settings were checked against current business needs and obligations. Each review should record who attended, what changed, which sensitivity types or systems were examined and the follow-up actions with owners. Assessors compare review dates against the annual review expected for the data management process and check that findings from one review were closed before the next. Schedule reviews in advance and keep the minutes or sign-off in the same repository as the schedule.

What meeting Safeguard 3.4 costs in money and effort

This table lists each cost component of meeting Safeguard 3.4, who is paid for it, whether it is one-time or recurring, what drives it up or down, and how to reduce it. Use it as a checklist when you ask any partner for a fixed-scope quote, because no supplied figures exist for these costs.

Cost component	One-time or recurring, and who is paid	What drives it up or down, and how to reduce it
Policy and retention schedule drafting	One-time to draft, then recurring at each annual review. Paid to internal staff or an advisor.	Up with the number of sensitivity types and data categories. Reduce by building on the Safeguard 3.1 data management process and its sensitivity levels.
Legal review of retention timelines	One-time for the initial schedule, recurring when laws or contracts change. Paid to counsel.	Up with the number of jurisdictions and contract types. Reduce by grouping data types with identical legal drivers and asking counsel to review only changed categories.
Engineering time to configure deletion or archival per system	Mostly one-time per system, plus recurring change work. Paid to internal engineers or an implementation partner.	Up with the number of systems, legacy stores and custom applications without native lifecycle features. Reduce by inventorying stores first (Safeguard 3.2) and standardizing on platforms with built-in retention jobs.
Tooling or licenses	Recurring where commercial products are used. Paid to vendors. Self-hosted open-source platforms remove license spend but not engineering time.	Up with commercial retention or archiving suites and per-seat or per-volume pricing. Reduce by choosing open-source components where they meet the documented requirement, and confirm each product's features in its own documentation.
Evidence upkeep	Recurring. Paid to internal staff, through retention job logs, deletion reports and change records.	Up with the number of systems producing evidence and the frequency of reviews. Reduce by centralizing logs and scheduling automated reports for each sensitivity type.
Backup and archive interaction review	Recurring. Paid to internal staff, since backup copies can hold data past its deletion date.	Up with the number of backup sets and long-term archives. Reduce by documenting backup retention separately and confirming that restores do not reinstate expired data.
External review or testing	Optional, recurring when used. Paid to an independent assessor or testing firm. DeployOpen prepares systems and evidence but does not issue reports.	Up with scope breadth and the number of systems tested. Reduce by fixing scope in writing and testing a representative sample of systems per sensitivity type.
Auditor sampling	Recurring at each assessment cycle. Paid to the independent auditor or certification body.	Up with the number of retention rules and exceptions to test. Reduce by keeping one owner, one rule and one evidence trail per sensitivity type so samples can be pulled quickly.

Open-source tools that support retention evidence

Safeguard 3.4 is about whether retention rules are written down and enforced, and each tool below can hold a piece of that proof. Their value lies in recording the schedule, controlling who changes it and showing what backups hold, not in deciding how long data lives. The organization still owns the retention timelines and the deletion decisions.

XWiki for the retention schedule

XWiki keeps every change to a page under version control, recording what changed, when and by whom. For Safeguard 3.4, this gives assessors a history of the retention schedule, so they can compare the minimum and maximum timelines in force at any past date and see when a rule was altered. Check that the schedule page is the controlled copy, that edits are traceable to named people, and that rollback is restricted to authorized roles. XWiki is licensed under LGPL-2.1-or-later. Confirm the version history settings in your own release.

BookStack for schedule approvals

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets the organization limit who can edit the retention schedule, while letting data owners read it and approvers sign off on changes. The evidence an assessor wants is a clear split between authors and approvers, with the approval record kept in the page itself. BookStack is licensed under MIT. Confirm how its role overrides behave in your version before relying on them for segregation of duties.

Bareos for backup expiry evidence

The Bareos Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of backed-up files. Restores can select files from the current backup or from one before a given date and time. For retention, this lets a team show which copies of a record still exist and when older copies were removed according to the configured expiry rules. Verify those rules against the retention schedule, since Bareos does not decide how long data must be kept. Bareos is licensed under AGPL-3.0-only. Confirm its pruning and expiry options in your version.

restic for backup integrity checks

restic check verifies the structural consistency of snapshots, trees and pack files. Run with --read-data or --read-data-subset, it reads pack files back to confirm the stored backup data is unmodified. This matters for retention because an assessor may ask whether retained backups are still readable and intact until their scheduled deletion. Keep the check output as dated evidence and confirm that the subset checks cover the retention window you claim. restic is licensed under BSD-2-Clause. Confirm the forget and prune behavior in your version, since expiry is a separate step from integrity checking.

Who owns retention, who can help, and where the auditor stops

Your organization owns the retention decisions. Safeguard 3.4 asks that data be kept according to the documented data management process, and that process must state both minimum and maximum timelines for each sensitivity type. Those timelines usually come from legal, regulatory, contractual and business requirements, and only your legal, compliance and data owners can decide them. Your team also approves any exception to a retention rule and operates the deletion or archival jobs that enforce it.

Timeline decisions: Set minimum and maximum retention periods per data category, with legal review and a named data owner for each.
Exception approvals: Record who can approve holds, extensions or early deletion, the reason, and the expiry date of each exception.
Operating deletion jobs: Run, monitor and correct scheduled purge or archive jobs, and keep the run logs.
Annual review: Confirm the retention schedule still matches the data management process, which CIS expects to be reviewed on a recurring basis.

Before you engage anyone, confirm internally which person signs off on each retention period and where those approvals are recorded.

Questions buyers ask about retention rules and outside help

Is enforcing data retention more work than the other Control 3 Safeguards?

Retention is usually less work to document than data inventory or classification, but more work to enforce across systems. Safeguard 3.4 depends on 3.1 and 3.2, so the team first needs a data management process and an inventory that say which data types exist and where they live. The effort then grows with the number of systems that hold data, the number of sensitivity types with different timelines, and how many of those systems have automated deletion or only manual cleanup. Ask any partner to size the work by counting systems and sensitivity types in the written scope, not by a generic day rate.

Can our own team enforce retention without an outside partner?

Yes, an in-house team can implement Safeguard 3.4 if it has the time, the system access and the authority to delete data. The organization owns its controls, so internal staff remain accountable for the retention schedule and the evidence. Outside help tends to make sense when the team lacks experience with automated deletion, when many legacy systems need configuration, or when the internal team cannot dedicate people to the work. An implementation partner prepares systems and evidence, but only an independent auditor or assessor issues reports or certificates.

What does retention work need from legal, system owners and change management?

Retention needs three inputs that engineering cannot supply alone. Legal or compliance must confirm minimum and maximum periods for each sensitivity type, including any legal holds. System owners must confirm where each data type is stored and whether their platform can delete or archive it on schedule. Change management must schedule deletion jobs, migrations and any downtime into approved windows, and record the approvals. Without these inputs, teams often set retention periods that conflict with contracts or regulations, or they turn on deletion that breaks reporting.

How long does retention enforcement take, and what drives the timeline?

The duration depends on the scope agreed in writing, and no standard figure applies across organizations. The main drivers are the number of data stores, whether deletion is already automated, the number of legal reviews needed for retention periods, and how many change windows are available. Work usually starts with the process and inventory, then moves to configuration of each system, then to testing that deletion works and is logged. Ask any partner for a phased plan that separates documentation, configuration and evidence collection, and confirm which dependencies sit with your own teams.

Does a written retention schedule alone satisfy Safeguard 3.4?

No, a schedule is necessary but not enough. Safeguard 3.4 asks the enterprise to retain data according to its documented data management process, with both minimum and maximum timelines. An assessor measures two things: whether the policy is complete, covering each sensitivity type, and whether it is enforced in systems. Enforcement needs evidence such as deletion job configurations, logs of executed deletions, exception approvals and sampling results. A schedule with no proof of execution will usually fail the enforcement measure.

How do backups affect our retention rules?

Backups can keep data beyond its retention period if they are not handled deliberately. A file deleted from production may still exist in backup sets for weeks or longer, depending on the backup rotation. The retention rule should state how long backup copies persist, and the backup policy should match it. Bareos can restore from the current backup or one taken before a given date and time, and restic can verify that stored backup data is unmodified, but neither decides retention on its own. Confirm backup expiry settings and the process for purging data from backup sets with the people who own recovery.

What should we ask a partner to include in a written scope?

A written scope should name the systems in range, the sensitivity types and their agreed minimum and maximum periods, and the deletion mechanisms to be configured. It should list deliverables, including the retention schedule, configuration records, test results and the evidence pack that an assessor will sample. It should state what the partner will not do, such as making legal determinations or issuing any attestation. Ask who approves retention periods, how changes after go-live are handled, and whether ongoing support is a separate retainer.

How DeployOpen scopes and prepares retention evidence

DeployOpen works on Safeguard 3.4 by preparing the retention rules, systems and evidence that the organization needs to show its data is kept only as long as its documented data management process allows. The organization owns its retention policy and decides the timelines, while DeployOpen implements and documents the technical enforcement inside the client's own infrastructure.

How we scope

Confirm which data types and systems fall under the retention rules, starting from the Safeguard 3.1 data management process and Safeguard 3.2 data inventory.
Record minimum and maximum retention timelines per sensitivity type as client-owned inputs in the written scope before work starts.
Agree in writing which systems, backup tiers and archives are in scope, and which evidence each deliverable will produce.

How we build

Configure retention and expiry settings in the self-hosted platforms that hold in-scope data, following the agreed timelines.
Set up backup retention and restore testing so recoverable copies also expire on the documented schedule, using tools such as Bareos or restic.
Test deletion and expiry behavior against sample records per sensitivity type and capture the results as dated evidence.

How we hand over

Deliver a retention rule register mapping each data type to its minimum timeline, maximum timeline, owner and enforcement mechanism.
Provide configuration exports, job logs and test records that an independent assessor can review against the assessment measures.
Document the operating procedure for reviewing retention rules and exceptions, with version history kept in the client's knowledge base.

How we support

Offer ongoing support and continuous checks on retention jobs as a retainer after the fixed-scope engagement ends.
Review retention rules when the data management process changes, so enforcement stays aligned with the documented policy.
Confirm with the client's auditor which evidence format and sampling approach they expect before final handover.