What Safeguard 3.5 requires for securely disposing of data
Safeguard 3.5 asks an enterprise to dispose of data securely, following the documented data management process, with the disposal method and process proportionate to how sensitive the data is. When an assessor or customer asks how data is destroyed at end of life, the answer should point to that process, the sensitivity classes it defines, and a record showing each disposal followed the matching method. Disposal is one of the places where the data management process either works or stays on paper, because the data often outlives the system it was stored on.
The risk sits in the copies. Residual data remains on retired disks, decommissioned virtual machines, backup sets, replicas, log stores, exports on laptops and tenants of software-as-a-service platforms that nobody remembers to clear. Each copy can outlive the business decision to delete the original. Disposal is hard to evidence for the same reason: a deletion command or a vendor's statement that data was removed does not show which copies existed, which method was used, or whether it reached backups. A reader should confirm, for each sensitive data type, where copies are created, who can trigger disposal, and what record is kept when it happens.
Safeguard 3.5 sits in the Data asset class and the Protect security function, and CIS assigns it to all three Implementation Groups. That placement makes it part of IG1 essential cyber hygiene, so an organization at the smallest scale is expected to meet it, and larger organizations with more sensitive holdings inherit it along with the stronger Control 3 Safeguards. Because it depends on the data management process and the data inventory, a gap in either usually shows up here first. Check the official CIS Controls Assessment Specification entry for Safeguard 3.5 before scoping evidence, since it defines what is measured.
Which disposal paths and data stores fall in scope
Safeguard 3.5 applies wherever sensitive data is kept, so the scope starts with an inventory of stores and disposal paths. The sensitivity tiers from Safeguards 3.1 and 3.2 decide which disposal method each store needs, and the cards below cover the stores that most often get missed.
Endpoints and removable media
Laptops, desktops, phones and USB drives are the most common carriers of data that leaves the organization by accident. Disposal here covers reimaging, device reassignment, repair returns and lease returns, as well as media that is handed to staff. Check whether the disposal process reaches devices that were never enrolled in central management, because those are often the ones nobody records. Ask who signs off on each device leaving service.
Servers and storage arrays
Servers, SAN and NAS arrays, and decommissioned hypervisor hosts keep data in places that standard file deletion does not reach. Disks may be pooled, replicated or controlled by a vendor firmware layer, so a logical delete leaves recoverable blocks. Confirm which method the sensitivity tier requires for each array model, and record who verified the result.
Databases and application stores
Databases keep data in tables, logs, replicas, snapshots and temporary files that outlive a row delete. Disposal here means deleting or cryptographically erasing records, then confirming that replicas, reporting copies and exports are also covered. Check that retention jobs and disposal jobs are tested against the data inventory, because a job that runs on a schedule does not prove the data is gone.
Cloud object storage and backups
Object buckets, block volumes, managed snapshots and backup repositories are the stores most often forgotten at disposal time. Versioning, lifecycle rules and cross-region copies can keep older versions after a deletion request. Backups need their own rule, because a restore point may hold data that the disposal process has already removed from production. Confirm how long backup copies persist and how that period is documented.
SaaS and service provider holdings
Data held by SaaS platforms, hosted analytics, support tools and outsourced processors is outside direct control but still in scope for disposal. The organization needs to know what each provider holds, how deletion is requested, and how the provider confirms it. Third-party disposal falls under Control 15, so provider contracts, deletion evidence and secure decommissioning terms should be checked together with this safeguard.
Paper and physical media
Printed records, archive boxes, tapes, optical discs and drives removed from equipment are physical stores that disposal processes often skip. Shredding, pulping and degaussing each suit different media and sensitivity levels, and paper stored off-site may sit under a vendor's contract. Confirm who collects the material, how the handover is recorded, and how destruction is witnessed or certified for the highest tier.
How an assessor tests disposal per sensitive data type
This table compares how an assessor reads each input, sample and evidence point for Safeguard 3.5 across sensitive data types. Use it to see where the six CAS measures bite in practice and where disposal programs usually fail. CIS defines what to measure, so the method for each data type is set by your own documented process.
| Assessment step | What the assessor checks | Common gap to close first |
|---|---|---|
| Inputs from Safeguards 3.1 and 3.2 | The documented data management process sets disposal rules by sensitivity, and the data inventory lists where each data type lives | Disposal rules that never reference the inventory, so no one can say which systems hold data due for disposal |
| Retention rules as a reference point | Disposal timing and method for each data type match the retention limits set under Safeguard 3.4 | Retention periods defined for some data types only, leaving others with no trigger for disposal |
| Sample of disposal events, customer records | Records selected from application databases and exports, with a dated disposal record and a method matched to the sensitivity tier | Deletion from the production database only, while replicas, exports and analytics copies persist |
| Sample of disposal events, backups and archives | Whether backup and archive sets holding expired data are tracked, expired on schedule or otherwise rendered unrecoverable | Untracked backups that keep restorable copies of data long after its documented disposal date |
| Sample of disposal events, end-user and removable media | Wiping or destruction method for laptops, drives and media, with a certificate or log tied to the asset | Reassigned or resold devices with no sanitization record linked to the asset inventory |
| Vendor and service provider disposal | Contract terms and destruction certificates for data held by providers, checked against the data flow documentation | Unverified vendor destruction where the provider's confirmation is a verbal assurance or missing entirely |
| Compare method to requirement | Whether the method used for each sample meets the level the documented process sets for that sensitivity tier | Single generic deletion method applied to all tiers, including data the process marks as highly sensitive |
| Measure roll-up into the two metrics | Completeness of the disposal process and compliance with the disposal process, each derived from the six measures | No tracked count of disposal events, so completeness and compliance cannot be shown with evidence |
How to build a disposal process that produces evidence
This sequence turns Safeguard 3.5 from a policy statement into disposal records that an assessor can trace from a retention trigger to a verified, documented destruction. Each step produces an artifact that the next one depends on.
Confirm sensitivity tiers and retention triggers
Start from the data management process (Safeguard 3.1) and the retention rules (Safeguard 3.4). Confirm the sensitivity tiers your organization actually uses, and for each tier list the events that start disposal, such as end of contract, end of a legal hold, expiry of a retention period or account closure. The data owner signs off on the list. Done means every tier has at least one written trigger and the owner has approved it. Assessors check this first because the disposal measures depend on it.
Build the data inventory link to disposal
Using the data inventory (Safeguard 3.2), record where each sensitive data type lives: primary systems, file shares, databases, endpoints, email, backups, SaaS applications and service provider environments. Each location gets an owner and a disposal responsibility. The output is a register that ties every data store to a tier and a trigger. Without this register, disposal tends to cover the systems people remember and miss the rest.
Map disposal methods to each tier
Create a method matrix that pairs each sensitivity tier with the disposal methods allowed for it, such as secure overwriting, cryptographic erasure, degaussing, physical destruction or deletion with confirmed removal from backups. Record which method applies to each storage type, and where a method cannot be verified, state the compensating step. The data owner and the security team approve the matrix. Confirm the method choices against your own legal, contractual and media-handling requirements, since the matrix must be proportionate to sensitivity.
Define the disposal workflow and approvals
Write the disposal procedure as a ticketed workflow. A request names the data set, tier, trigger, storage locations and planned method. The data owner approves, the operator performs the disposal, and a second person verifies the result before the ticket closes. Ticket fields should capture who acted, when, the method used and the verification outcome. Keep the procedure and template under version control so changes are traceable. Done means a sample ticket can be completed end to end by someone who did not write the procedure.
Extend disposal to backups, cloud and vendors
Disposal often fails at the edges. Define how deleted data is removed from backup sets, replicas, snapshots and archives, and how cloud storage and SaaS deletion is confirmed, including any provider-side retention windows you need to confirm with the provider. For service providers that hold sensitive data, the contract should require disposal at termination and a written confirmation in the same format as your internal records. Record each vendor's method and confirmation standard in the register from step two.
Run a pilot disposal with recorded verification
Choose a low-risk data set in a non-production or archive environment and run the full workflow from request to closure. Record the evidence: the approved ticket, the method applied, system logs or tool output showing the deletion, the verification result and the signed closure. Review the pilot with the data owner and fix gaps in the procedure. The output is a worked example of one complete evidence chain, which becomes the reference for production disposals.
Set the certificate of destruction standard
For disposals performed by a third party or for physical media, define a certificate of destruction standard. It should list the asset or serial identifiers, the data classification, the method, the date, the performing party, the witness or verifier and the signature. Require the same fields for vendor-performed disposals. Confirm with your vendor and your own legal team which fields they can provide, because the standard should be achievable before you write it into contracts.
Set the review cadence and measure completeness
Set a review cadence for the process, the method matrix and the register, and confirm it against the review frequency in your data management process. Track two measures over time: whether every disposal ticket for a tier has the required fields and approvals (compliance to the process), and whether every data location in the inventory has a documented disposal path (completeness of the process). Report both to the owner of the data management process. Ask your assessor which samples they will pull so the records are easy to produce.
Matching disposal methods to sensitivity
Electronic storage you own or operate, such as servers, workstations, NAS devices and storage arrays, is where most disposal decisions start. The method should match the sensitivity recorded in your data management process: a lower-sensitivity file share may be acceptable to reformat or delete through the operating system, while data classed as sensitive usually calls for a method that makes recovery impractical, such as overwriting with verification or cryptographic erase on encrypted volumes. Degaussing applies to magnetic media only and does not work on solid-state drives, so confirm its suitability with the drive vendor before relying on it.
- Overwriting: Multi-pass or single-pass overwrites, with the pass count and tool version recorded against the asset.
- Cryptographic erase: Destroying the encryption keys for a volume that was encrypted from the start, which can be quicker and easier to evidence.
- Degaussing: Applicable to certain magnetic media only; record the device and field strength the vendor specifies.
- Evidence: Tool logs, a hash or sector verification report, the asset identifier and the operator's name and date.
- Low-sensitivity methods: Standard deletion or reformatting may suffice for data your documented process classes as low sensitivity.
Confirm specific pass counts, tools and degaussing parameters against your own standards and the media vendor's instructions before you write them into the procedure.
In cloud and SaaS environments you usually cannot overwrite the underlying storage yourself. Disposal depends on the provider's deletion behavior and on whether the data was encrypted with keys you control. The practical approach is to delete the data through the service, confirm the deletion through the provider's documentation or console, and destroy or disable the customer-managed keys that protected it. Ask each provider for its written data deletion terms, including how long backups and replicas persist after deletion.
- Provider deletion: Deletion through the service interface or API, with the time and actor captured in the provider's logs.
- Key destruction: Scheduling or performing destruction of customer-managed keys so that remaining ciphertext cannot be decrypted.
- Backup and replica windows: Confirm with the provider how long copies persist after deletion and document that period in your process.
- Evidence: Provider audit logs, key deletion records, the provider's data deletion statement and the ticket that authorized the action.
- Low-sensitivity methods: Standard service deletion may be acceptable where the documented process allows it and no retention obligation applies.
Ask the provider which disposal features apply to your service tier and region, and confirm them in your contract.
Physical media includes drives, tapes, optical discs, printed records and devices returned from service. Where the data is sensitive, the disposal decision is often whether the media is destroyed on site, destroyed by a contracted vendor, or sanitized and reused. Destruction by a vendor should come with a certificate that identifies the media, the method and the date, and you should retain that certificate as the evidence of disposal. Shredding particle size and destruction standards should be set by your own requirements and confirmed with the vendor.
- Shredding or crushing: Physical destruction to a size your standards specify, witnessed or recorded where your classification requires it.
- Destruction certificates: Records listing the serial numbers or asset tags destroyed, the method, the date and the vendor's authorized signatory.
- Chain of custody: Transfer records from collection to destruction, especially when a third party handles the media.
- Reuse after sanitization: Only where the sanitization method is documented and verified for the sensitivity involved.
- Low-sensitivity methods: Recycling or donation may be acceptable for media that holds no sensitive data after verified sanitization.
Confirm destruction standards and certificate contents with your vendor, and check that the certificate names every asset in scope.
Disposal evidence that passes an assessment
An assessor testing Safeguard 3.5 wants to trace a disposal from the documented process to a record that proves the data is gone. The cards below cover the artifacts that make that trace possible and the routines that keep them current between assessments.
Disposal policy and method matrix
The matrix maps each sensitivity level from the data management process to an approved disposal method, such as secure overwriting, cryptographic erasure, physical destruction or deletion with backup expiry. It is the reference point for every other record. Check that each data type in the data inventory has a row, that the owner signed off, and that the matrix states who may approve an exception and how exceptions are recorded.
Disposal tickets linked to inventory records
Each disposal should open a ticket that names the asset or dataset, its entry in the asset inventory or data inventory, the method used and the approver. Assessors commonly pick a sample of tickets and trace them back to inventory entries to confirm the record is closed and the inventory is updated. A ticket that cannot be linked to an inventory item shows that the inventory and the disposal process have drifted apart.
Sanitization and destruction logs
Sanitization logs record the device serial number, the tool or procedure used, the operator, the start and end time, and the verification result. For cloud storage, logs should capture the deletion request and the provider confirmation. Confirm that logs are written at the time of disposal, cannot be edited by the operator, and reference the same identifier as the disposal ticket.
Vendor destruction certificates
When a third party destroys media or hosts data that is later removed, obtain a certificate of destruction that names the items, the method, the date and the destruction facility. Compare certificate serial numbers against the list sent to the vendor. This evidence links to Control 15 provider management, so the contract should require certificates within an agreed period and state what happens when a vendor cannot produce one.
Cryptographic key destruction records
Where data is disposed of through cryptographic erasure, the evidence is the destruction of every key that can decrypt it, including copies in key backups and hardware security modules. Records should show the key identifier, the key store, the destruction action and the operator, and should confirm that no escrowed copy remains. Ask whether the encrypted copies of the data are also removed from backup sets that rely on that key.
Backup expiry and periodic reviews
Disposal is incomplete while backups hold copies past the retention limit, so keep records of backup rotation and expiry jobs, along with the date each expired set was overwritten or deleted. Schedule a periodic review that compares retention rules with actual deletions and records findings. Tie this review to the annual data management process review so the assessor sees a closed loop from policy to proof.
What meeting Safeguard 3.5 costs in money and effort
This table breaks down the cost components of disposing of data under Safeguard 3.5, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No fixed figures are given because the supplied facts do not include any, so use the table to structure quotes and internal budgets. The main takeaway is that the largest recurring costs usually come from evidence upkeep and sampling, not from the disposal act itself.
| Cost component | Who is paid or who spends effort | One-time or recurring, and main driver |
|---|---|---|
| Sanitization and destruction tooling | Tool vendors for licensed wiping or degaussing software, or the destruction service provider for physical media | Licenses and service contracts recur. Driver: number of device types and media classes in scope |
| Certificate of disposal management | Internal records owner, or a document system such as a self-hosted wiki or ticketing tool | Setup is one-time. Recurring effort follows the volume of disposals and the number of sensitivity tiers |
| Workflow build (disposal process and tickets) | Internal engineering or an implementation partner building ticket templates, approvals and method rules | One-time. Driver: number of data stores and systems that need hooks into the process |
| Open-source logging and ticketing | Internal staff or implementation partner for installation, hardening and upkeep | Software is typically free to license. Recurring effort covers hosting, patching and backups |
| Evidence upkeep | Internal control owner, who keeps disposal records, method evidence and exception logs current | Recurring. Driver: how often disposals occur and how many records each one generates |
| Vendor due diligence on disposal providers | Internal procurement and security teams, sometimes with outside assessors | Initial review is one-time. Re-review recurs with contract renewals and provider changes |
| External review and auditor sampling | Independent auditor or assessor, who samples disposal records and tests method by sensitivity | Recurs with each assessment cycle. Driver: number of sampled disposals and data types in scope |
| Gap remediation | Internal teams or an implementation partner fixing missing or inconsistent disposal records | Occasional. Driver: maturity of the data management process and the data inventory at the start |
How self-hosted open source supports disposal evidence
Self-hosted documentation tools can hold the disposal records that show Safeguard 3.5 is operating, but they do not dispose of anything. Sanitization, deletion and destruction happen in storage platforms, backup systems, endpoints and with service providers. The wiki or knowledge base is where the organization keeps the documented disposal policy, the method matrix that maps each sensitivity level to an approved disposal method, and the signed records of who approved each change. Assessors measuring the completeness and compliance metrics for this Safeguard will want to see that the matrix is current and that the procedure in force is the one staff followed. XWiki is a candidate for that role because it keeps every change to a page under version control, recording what changed, when and by whom, and it lets reviewers compare any two versions and roll back. For disposal evidence, that means the method matrix and procedure can show a dated revision history that links each change to a named editor, which supports the annual review expected under the data management process in Safeguard 3.1. Confirm with the vendor how page history is retained, exported and backed up in your environment, and whether approval workflows can be enforced inside the tool or must be recorded by a separate process.
BookStack, which is MIT-licensed, controls who can edit or approve disposal procedures through roles. User abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical design is to place the disposal procedures in a restricted book where only the data owners and the compliance lead can edit, while operations staff hold read access. Doing so separates the people who write the disposal method from the people who carry it out, a distinction an assessor will look for when reviewing who may change the rules. Before relying on this model, confirm the exact role and permission settings in your installed version, test them with a non-administrative account, and check whether the tool can produce an access report for the reviewer. Also decide where approval evidence lives, since a page edit alone does not prove a sign-off. Disposal certificates, tool logs and vendor destruction records should be stored in a controlled location that the wiki links to, and any integration between these systems should be confirmed with each vendor before it is designed into the process.
Who owns disposal, who helps, and where the auditor stops
Your organization owns Safeguard 3.5. The control asks that data be disposed of securely as the documented data management process requires, and that the method be proportionate to sensitivity. That means your people must decide what each data type needs, approve the methods, carry out disposal and keep the records. No outside party can accept that accountability on your behalf.
- Approval of methods: Accountable owners sign off the disposal method for each sensitive data type, including who may authorize exceptions.
- Execution: System, application and facilities staff perform disposal under the documented process, including media destruction and cloud deletion.
- Records: Your team creates the tickets, certificates of destruction and logs that prove each disposal happened.
- Upstream inputs: Safeguards 3.1 and 3.2 supply the sensitivity levels and data inventory that disposal depends on, and only your teams can keep them current.
- Review: Owners check disposal performance against the process at the review interval your data management process sets.
Before relying on any partner, confirm internally who signs the disposal policy and who can show a sampled record within a short timeframe.
An implementation partner helps you prepare the material and systems that make disposal measurable. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments, but it does not approve your methods, perform your disposals as your control owner or issue any report. The partner's work is preparatory and should be defined in a written, fixed scope before work starts.
- Method matrix: A draft mapping of sensitive data types to disposal methods, for your owners to review and adopt.
- Workflows: Ticketed disposal procedures that create a record at each step, configured in your self-hosted platforms.
- Evidence templates: Standard forms for destruction certificates, deletion logs and exception approvals.
- Sampling-ready records: Systems configured so that a single disposal can be traced from request to completion.
- Handover: Documentation and training so your staff can run the process after the engagement ends.
Ask any partner to state in writing which deliverables it produces and which decisions remain with your organization.
An independent auditor, assessor or certification body tests whether Safeguard 3.5 is implemented and reports on it. Only that independent party issues reports or certificates. The CIS Controls Assessment Specification defines measures for this safeguard, including completeness of the disposal process and compliance to it, so the auditor will check both the design of your process and the records of its operation.
- Design review: The auditor reads the disposal process and checks it covers each sensitive data type.
- Sample testing: The auditor selects disposals and asks for the supporting records.
- Gap identification: Missing methods, missing records or exceptions without approval appear as findings.
- Independence: The auditor cannot design the controls it tests without losing that independence.
- Scope limits: Auditors do not judge whether your business decisions about retention or sensitivity are correct, only whether your documented process is followed.
Confirm with any auditor which assessment type and reporting format it will use before you collect evidence.
CIS Controls Accreditation is a separate program from audit. CIS runs it with CREST and accredits CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services. Holding or working with an accredited provider does not replace an independent assessment of your own environment, and DeployOpen does not hold CIS Controls Accreditation unless that status is confirmed in writing.
- What accreditation covers: The provider's qualifications to deliver CIS Controls services under CIS's program.
- What audit covers: Your organization's implementation, tested by an independent party.
- Fees: CIS lists an application fee for accreditation of $1,500 for CREST members and $2,500 for non-members.
- Confusion to avoid: Do not present an accredited implementer's work as an audit result.
- Verification: Ask any provider for its current accreditation status and scope.
Before you select a partner or auditor, ask each one to name its role, its accreditation if any, and the deliverables it will sign.
Where disposal programs usually fall short
Most disposal programs have a written procedure but fail at the edges: copies that sit outside the main system, retention clocks that never trigger disposal, and evidence that nobody checked. Each gap below is one that an assessor measuring Safeguard 3.5 can find, and each card ends with a check you can run before the assessment.
Backups and replicas never disposed
Disposal often removes the production record but leaves backup sets, disaster recovery replicas and reporting copies untouched. These copies usually have their own retention schedules, so data expected to be gone can persist for longer than the documented process allows. Confirm that your disposal procedure names every backup tier and replica, and that each has a rule for when its copies expire and how expiry is recorded.
SaaS and vendor copies untracked
Sensitive data frequently reaches SaaS platforms, analytics tools and service providers through integrations that the data inventory does not capture. When the record is deleted internally, copies held by the provider or exported into a spreadsheet remain. Ask each data owner to list the external systems that receive their data, and confirm that the disposal request reaches each one, including the provider's own deletion process.
No link between retention expiry and disposal
Retention rules are often set in the data management process, but nothing triggers disposal when a retention period ends. Records then age past their limit without anyone acting on them. Check whether retention expiry generates a disposal ticket or scheduled job with a named owner, and whether the disposal log records the original retention date next to the disposal date so an assessor can compare them.
Destruction certificates never verified
Many programs accept a vendor's destruction certificate as proof and file it without checking what it covers. A certificate may name a device batch rather than the specific assets, or describe a method weaker than the sensitivity level requires. Before accepting one, confirm the certificate identifies the assets or media, the method used, the date and the sensitivity class, and record who reviewed it.
Key destruction not recorded
For data encrypted at rest, deleting the ciphertext is only part of disposal. If the encryption keys remain in a key store, copies of the data may still be recoverable, and if keys are destroyed without a record, the organization cannot show that the data is unrecoverable. Confirm that key destruction is a defined step in the disposal procedure, that it is logged with the key identifier and date, and that backup copies encrypted under the same key are covered.
Questions buyers ask about Safeguard 3.5
What does securely disposing of data under Safeguard 3.5 cost?
The cost comes mostly from people time and tooling, not from a fixed fee. Your team pays for time to define disposal methods per sensitivity level, update the data management process, and record disposals. Costs rise with the number of data stores, the number of systems holding sensitive data, and the number of service providers that keep copies. Disposal tools, such as secure erase utilities or certified destruction services for physical media, carry their own costs and recur only where you buy them as a service. Ask any implementation partner for a quote built from a written scope that lists the data stores in scope, the disposal methods required for each sensitivity class, the evidence to be produced, and which items are one-time versus recurring.
How long does it take to get Safeguard 3.5 in place?
Duration depends on how far your data management process and data inventory already go. Safeguard 3.5 depends on Safeguards 3.1 and 3.2, so if no documented process or inventory exists, that work comes first and usually sets the schedule. Remaining steps are mapping disposal methods to each data type, configuring or procuring tools, testing disposal on representative systems, and collecting the first round of records. Ask for milestones in the written scope with dependencies shown, and confirm the schedule against your own change windows and approval cycles.
What does the work need from our team?
Safeguard 3.5 needs decisions that only your organization can make. Data owners must confirm sensitivity classes and retention end points. System owners must confirm which platforms hold data and what disposal options each supports. Security and compliance staff must approve disposal methods and the exception process. Operations staff run disposals and keep records. Before work starts, ask who signs off each disposal method, who holds the disposal logs, and how often the process is reviewed.
Can we do Safeguard 3.5 in-house without outside help?
Yes, if you have people who understand your data stores and can write and test a disposal procedure. The Safeguard is a process requirement, so internal teams can own it fully. Outside help tends to be useful where the number of platforms is large, where backup copies and replicas are hard to reach, or where the team lacks experience with storage-level sanitization. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and prepares evidence for assessments, but it does not issue audit reports or certifications. An independent auditor or certification body issues those.
What will an assessor sample when testing Safeguard 3.5?
An assessor will look for the documented disposal process, proof that it covers the sensitive data types identified in your inventory, and records showing that disposals followed it. Under the CIS Controls Assessment Specification, the measures for this Safeguard are combined into two metrics: completeness of the disposal process and compliance with it. In practice, expect requests for a sample of disposal records, the method used for each sample, evidence of completion (such as a log entry or certificate of destruction), and exceptions with approvals. Confirm the sample size and selection rules with your chosen assessor before you collect evidence.
How do Safeguards 3.1, 3.4 and Control 15 relate to Safeguard 3.5?
Safeguard 3.1 sets the documented data management process, including sensitivity levels, ownership and disposal rules. Safeguard 3.5 applies that process when data is removed. Safeguard 3.4 defines how long data is kept, so retention end points tell you when disposal is due. Control 15 matters when a service provider holds your data, because disposal must reach their systems too. Ask providers for their disposal procedures and certificates, and include secure decommissioning terms in the contract. Confirm how each provider's disposal records will reach your evidence set.
How DeployOpen prepares disposal controls and evidence
DeployOpen helps prepare the disposal controls and the evidence that shows them working, but the organization owns the disposal decisions and the assessor or auditor issues any report. In practice, DeployOpen plans, implements and documents self-hosted systems and evidence workflows inside the client's own cloud accounts, data centers or air-gapped networks. For Safeguard 3.5, that can mean configuring the systems that hold disposal records, such as a ticketing or wiki platform with version history, and setting up permissions so that only the named data owners and administrators can approve or close a disposal. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and they will test the evidence against the client's own documented data management process.
Work is delivered as a fixed-scope engagement. Before any work starts, the scope, the systems in scope, the deliverables and the timelines are agreed in writing. For disposal, a typical written scope would list the data types covered, the disposal methods expected for each sensitivity level, the systems where disposal records will be kept, and the documents handed over at the end. Ask whether the scope includes reviewing the disposal method against each sensitive data type, or only configuring the evidence store. A quote follows from that written scope, so the more exact the scope, the more exact the quote. Ask for the quote to separate one-time setup from any recurring effort.
Disposal evidence is not a one-off task. Records need to be kept current as systems are retired, storage is repurposed and service providers are changed. Retainers cover ongoing support, upgrades and periodic checks of the disposal records and the platforms that hold them, and they are available on request. Before committing, confirm with DeployOpen which of these activities are included in a retainer and which would be scoped separately, and confirm with your own assessor which evidence formats they accept for disposal, such as signed tickets, certificates of destruction or system logs.
