What Safeguard 3.14 asks you to log for sensitive data access
Safeguard 3.14 asks the enterprise to log access to sensitive data, including when that data is modified or disposed of. It sits in the Data asset class and the Detect security function, and CIS v8.1 assigns it to Implementation Group 3 only, so it is a requirement for enterprises with security specialists and regulated, sensitive assets. The risk it addresses is misuse or exfiltration of sensitive data going unnoticed: an insider copying a customer file, a compromised account reading records it has no business need to touch, or a process deleting data before anyone sees it. Without a record of who touched which sensitive data and when, an investigation can confirm that a breach happened but not what was taken. CIS publishes the Controls free for organizations to use to improve their own cybersecurity, but states that the Controls do not replace any regulatory or compliance scheme. CIS cross-references this Safeguard to NIST SP 800-53 AC-6(9), AU-2, AU-12 and SI-4(20), ISO/IEC 27001:2022 Annex A 8.15, SOC 2 CC6.1 and PCI DSS v4.0 requirements 10.2.1 and 10.2.1.1. Confirm which of those cross-references your auditor or customer expects before you map your evidence to them.
The logging is hard for three reasons. First, you cannot log access to sensitive data you have not identified, so the data inventory described under Safeguard 3.2 must exist first. Second, the events must reach a central place that is protected from the systems being watched, which is where Control 8 audit log management comes in: collection, time synchronization, retention and review of the logs carry most of the weight of this Safeguard. Third, the log must be able to show that a record was sensitive, which requires the classification and inventory work to be connected to the log sources. Decide early which systems hold sensitive data (databases, file shares, application data stores, secrets managers), which events count as access, modification or disposal for each, and who reviews the resulting records.
Open-source tooling can supply parts of this evidence, but none of it decides scope for you. Nextcloud's admin_audit app writes additional event information to an audit.log file in the data directory, or to a path set with logfile_audit, which gives you file-level access records for that platform. OpenBao audit devices keep a detailed JSON log of every API request and response, with most sensitive values hashed using HMAC-SHA256, which helps you show who read or changed secrets. Wazuh file integrity monitoring records a baseline of checksums and attributes and alerts when a user or process creates, modifies or deletes a monitored file, including who made the change. Bareos Verify jobs compare files against previously cataloged attributes, which helps detect changes after the fact. Confirm with each vendor whether a given event type is captured in your version and configuration before you rely on it, and have an independent assessor decide whether your logs satisfy the Safeguard.
Which systems, data and teams Safeguard 3.14 covers in scope
Safeguard 3.14 is only as complete as the scope behind it. The decisions below determine which stores, applications, accounts and providers must produce access logs, and each one changes how much logging, storage and review the organization has to run. Settle them in writing before configuring any logging.
Sensitive data stores from the data management process
Start with the sensitivity levels defined in the data management process under Safeguard 3.1, then match them against the data inventory under Safeguard 3.2. Every store that holds data at or above the sensitive level belongs in scope, including backups, exports and analytics copies. Check whether the inventory is current, because a store missing from it will also be missing from the logging scope. Missing stores are the most common gap.
Applications and databases that read or change sensitive data
Applications often read sensitive records through service layers, so the database log alone may not show which user or process made a request. Include the application tier, the database engine and any reporting or export function that returns records. The scope decision here sets whether logs capture the originating user identity or only a shared database account, which affects whether the logs can answer who accessed a record.
File shares, object storage and document platforms
Network file shares, object buckets and document management platforms hold sensitive data outside formal applications, so they are easy to leave out of scope. Confirm which shares contain sensitive files, whether read, modify and delete events are available from the platform, and whether the file system or a monitoring agent records them. Modification and disposal events matter as much as reads, because Safeguard 3.14 names both.
Privileged, administrative and service accounts
Decide whether administrators, database owners, backup operators and service accounts are in scope. Shared or service accounts often bypass per-user logging, so the scope should require that their actions on sensitive data are attributable to a named owner or a documented process. Confirm how credential vaults and secrets platforms record retrievals, since those events can reveal access to sensitive stores indirectly.
Service providers and hosted platforms
Any third party that stores or processes sensitive data on the organization's behalf creates logging obligations that depend on the contract. Identify which providers hold sensitive data under the data flows documented for Safeguard 3.8, and confirm in writing whether they supply access logs, how long they retain them and how the organization receives them. Logs the organization cannot obtain do not satisfy the Safeguard for that store.
Teams that own the logs and the review
Scope also covers the people who must act on the logs. Assign owners for each in-scope store, for the audit log pipeline described under Control 8, and for periodic review of sensitive data access. A log stream with no named reviewer shows that data is captured but not that access is checked, so record who receives alerts and who signs off on exceptions before the logging scope is declared complete.
How an assessor tests the CIS Safeguard 3.14 coverage metric
This table walks through how an assessor is likely to approach the coverage metric for Safeguard 3.14, from the prerequisite inventories to the evidence requested and the findings that most often appear. Read it as a preparation checklist for your own environment, not as a description of any specific assessor's procedure. The Assessment Specification defines what to measure, so the conclusions an assessor reaches come from their own testing.
| Test area | What the assessor looks for | Evidence usually requested | Common finding |
|---|---|---|---|
| Prerequisite inventories | Whether the enterprise asset inventory (1.1), software inventory (2.1) and secure configuration process (4.1) identify where sensitive data lives and which logging is enabled | Current asset and software inventory exports, documented secure configuration baselines, and the list of systems tagged as holding sensitive data | Sensitive data stores are missing from the inventory, so they never enter the measurement |
| Sensitive data stores in scope | Whether every system that holds sensitive data is identified and mapped to the data management process and data inventory | Data inventory extract, sensitivity labels, and a reconciliation between the data inventory and the systems subject to logging | Shadow databases, file shares or SaaS exports that hold sensitive data but are not in scope for logging |
| Logging configuration | Whether access to sensitive data, including reads, changes and deletions, is captured by the platform or application that stores the data | Screenshots or configuration files showing audit logging enabled, the event types captured, and the log destination for each in-scope store | Logging turned on for login events only, with no record of data reads, modifications or exports |
| Sample of access and change events | Whether a sample of access, modification and export events on sensitive data appears in the logs with user, time, object and action | A sample of log entries selected by the assessor, with the matching source records or tickets that explain why each access occurred | Events appear in logs but lack the user identity, object or action, so the entry cannot show who accessed what |
| Disposal events | Whether deletion and disposal of sensitive data is logged in the same way as access, consistent with the data management process | Disposal records and the matching log entries for a sample of disposal actions, including backups or archives where applicable | Disposal is performed through a batch job or direct database command that writes no audit record |
| Log protection and location | Whether logs are stored in a location the source system administrators cannot quietly alter or remove | Log destination settings, access controls on the log store, and evidence of centralized collection under the audit log management controls in Control 8 | Logs are kept only on the source host, where a privileged user can edit or delete them |
| Log review | Whether someone reviews sensitive data access logs on a defined basis and acts on anomalies | Review records, alert rules or tickets showing who reviewed the logs, when, and what follow-up was taken | Logs are generated and retained, but no review record exists for the period under assessment |
| Coverage calculation | Whether the five measures are combined into the single coverage metric across the in-scope sensitive data stores | The assessor's own count of in-scope stores with logging enabled, measured against the documented inventory | The enterprise's internal coverage figure is higher than the assessor's count because the denominator omits some stores |
How to implement sensitive data access logging step by step
This sequence turns Safeguard 3.14 into a working control by tying each logged event to a named data store, a named log source and a documented review routine, so the evidence an assessor asks for already exists when the audit starts.
Confirm the sensitive data inventory and classification
The data owner and security lead confirm which data stores hold sensitive data, using the data inventory and classification labels produced under Safeguards 3.2 and 3.7. Every later step depends on this list being complete, so any store found during discovery goes back into the inventory before logging work begins. The output is a signed-off sensitive data inventory that names each store, its owner and its sensitivity label. The step is done when the security lead can point to every store in the list and an owner has accepted responsibility for it.
Inventory systems and accounts that reach each store
Engineers map every application, service account, administrator path, integration and batch job that can read, change or delete data in each sensitive store. This work draws on the asset and software inventories from Safeguards 1.1 and 2.1 and on the secure configuration records from Safeguard 4.1, which the assessment specification treats as prerequisites. The output is an access path register that lists each route to each store. The step closes when a reviewer can trace every route to a named account or process.
Enable access, modification and disposal logging per system
Each system in the register gets logging turned on for reads, writes and deletions of sensitive records, using whatever the platform provides, such as an application audit app, an audit device on a secrets engine or file integrity monitoring on directories that hold exported or stored sensitive files. Administrators confirm that the setting is applied in configuration management, not only on a single host. The output is a logging configuration baseline with one entry per system, including the setting, the file or device path and the event types covered. The step is done when a test read, change and deletion each produce a log entry.
Forward sensitive access logs to the central store
The platform team connects each log source to the central log store set up under Control 8, so sensitive access events are collected, time-synchronized and kept in a location the application owners cannot edit. Local audit files stay as a secondary copy where the platform requires it. The output is a log source register that records each source, its forwarding method, its collector and the destination index. The step is done when events from each source appear centrally and a sample event can be matched to its origin.
Define sensitive event fields and retention
The security lead and data owners agree which fields every sensitive access event must carry, typically the actor, the action, the object, the time, the source address and the outcome, and they check that each source records those fields or can be configured to. Retention periods for these events are set against the retention rules in the data management process from Safeguard 3.1 and any legal or contractual requirement the organization must meet. The output is a sensitive event schema and a retention schedule. The step is done when a sample event from each source contains every required field and the retention setting matches the schedule.
Document a review and alert routine
The organization writes down who reviews sensitive access events, how often, which patterns trigger an alert, such as access by an account outside the approved list or deletions outside a disposal job, and how the alert is routed to incident response under Control 17. The routine also covers reviews of the logging configuration itself, so a disabled audit setting is noticed. The output is a documented review procedure and an alert rule set, with a record of the first completed review. The step is done when the reviewer can show that the routine ran and that a test alert reached the responsible person.
Evidence that shows sensitive data access is logged
An assessor testing Safeguard 3.14 starts with the question of what sensitive data exists and where it lives, then works outward to the logs that record access, change and disposal. The cards below cover the artifacts that answer that chain, and each one needs a named owner and a refresh trigger so the evidence still matches the environment when the assessor arrives.
Scoped list of sensitive data stores
This is the starting point for every other artifact: a list of the databases, file shares, object buckets and applications that hold sensitive data, drawn from the data inventory under Safeguard 3.2. An assessor uses it to confirm that logging covers the stores that matter, not only the ones that are easy to log. Check that each store names its data type and owner. Refresh it whenever a new store is provisioned, with the change ticket linked to the list.
Logging configuration exports per system
For each in-scope system, keep an export of the audit logging configuration as it stood during the review period, such as the audit app settings, audit device configuration or file integrity monitoring policy. The export shows which events are captured and where they go. Confirm that sensitive data stores are actually enabled, since a system with logging turned off still appears in an inventory. Schedule the export so each review period has a dated copy.
Sampled access, change and disposal entries
Keep representative log entries showing reads, modifications and deletions of sensitive records, each with a timestamp and the identity of the actor. Assessors look for the three event types named in the Safeguard, so include disposal events as well as ordinary access. Sample across systems and across time, and check that the actor is a named user or service identity, not a shared account. Pull samples on a schedule rather than only when an audit is announced.
Central log store and retention settings
Show where sensitive access logs are collected, how they are protected from alteration, and how long they are kept. Record the retention setting and the access controls on the log store itself, because a log store that the administrators of the monitored system can edit provides weak evidence. Confirm retention against the data management process under Safeguard 3.1 and the retention rules in Safeguard 3.4. Export the settings at each review and file the export with the date.
Alert and review records
Logs only support the Safeguard when someone reads them. Keep records of alerts raised on sensitive data events, the review of those alerts, and the outcome of each investigation. Include the periodic review of access logs for stores with high sensitivity. Record who reviewed, when, and what action followed, including cases closed with no action. Connect these records to the incident response process where an alert becomes an incident.
Register of log sources
A register lists every source that feeds the central log store, including the sensitive data stores, their log type and their owner. It is the document that lets an assessor test coverage: any store missing from the register is unlikely to be monitored. Compare the register against the data store list at each review and record the differences. Assign an owner for keeping the register current and link each new source to its onboarding ticket.
Open-source tools that produce sensitive data access evidence
Safeguard 3.14 is satisfied with records, not intentions. The four tools below each produce a different kind of record: application audit logs, secrets engine request logs, file change alerts and backup verification results. Map each one to the data stores it actually touches, then confirm what each captures before you name it as evidence.
Nextcloud admin audit logging
Nextcloud is licensed under AGPL-3.0-only. Its admin_audit app writes additional event information to audit.log in the data directory, or to a path you set with logfile_audit. For Safeguard 3.14, this is the candidate source for access events on files stored in the platform. Confirm with your own configuration which file, sharing and admin events are recorded, which user identity each entry carries, and whether deletions and modifications of sensitive files appear. Then decide where the log is shipped so it cannot be altered by the users it records.
OpenBao audit devices
OpenBao is licensed under MPL-2.0. Its audit devices keep a detailed JSON log of every API request and response, including errors, and most sensitive values are hashed with HMAC-SHA256. This makes it a strong source for access to secrets and encryption keys that protect sensitive data. Confirm that every mount holding data-protection secrets is covered by an enabled audit device, that the log reaches storage you control, and that your team can tie each entry to a principal. Hashing protects values in the log but does not replace reviewing who requested them.
Wazuh file integrity monitoring
Wazuh is licensed under GPL-2.0-only. Its file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, then alerts when a user or process creates, modifies or deletes a monitored file. Alerts can run on a schedule or in real time and include how and when a file changed and who changed it. This covers modification and disposal of files on hosts you monitor. Confirm which directories holding sensitive data are in scope, whether database files and mounted shares are covered, and how alerts are routed and reviewed.
Bareos verify jobs
Bareos is licensed under AGPL-3.0-only. Its Verify jobs compare files against attributes previously cataloged in the backup catalog, which gives a Tripwire-like capability for detecting changes after a break-in. For Safeguard 3.14, this shows whether backed-up sensitive data was altered between backups, but it runs on a schedule and records changes against the last catalog entry rather than each individual access. Confirm the verify level you select, the file sets that cover sensitive stores, and whether removals made by the disposal process appear as expected changes or as unexplained gaps.
What meeting Safeguard 3.14 costs in money and effort
This table breaks the cost of meeting Safeguard 3.14 into its components, showing who is paid for each, whether it is one-time or recurring, what pushes it up or down, and what to request in a quote. Use it to compare an internal build against outside help, and to check that a proposal covers the costs that usually surprise teams. No figures are given here because none were supplied for this Safeguard.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|---|
| Tooling and licenses | Software vendors (none for the named open-source tools); staff time to deploy | One-time setup, then recurring if a paid SIEM or support contract is added | Choice of open-source versus commercial platforms, and whether a SIEM already exists | Confirmation of which components carry license terms, and any paid support or subscription tiers |
| Storage and hosting for audit logs | Cloud or data center providers, or internal infrastructure teams | Recurring | Log volume, number of sensitive stores, and retention period | Estimated daily log volume, retention period assumed, and storage tier used |
| Data inventory work that precedes logging | Internal data owners, with an implementation partner if one is engaged | One-time, then recurring when the inventory changes | Number and complexity of sensitive data stores, and how current Safeguard 3.2 work already is | Written list of which stores are in scope and who validates the list |
| Engineering time to enable and forward logs | Internal platform or security engineers, or a fixed-scope implementation partner | One-time for enablement, recurring for changes to sources | Number of applications and databases, and whether sources already log to a central point | Named deliverables per data store, test approach, and what counts as done |
| Access and modification event coverage testing | Internal security engineers or an external tester | One-time, then periodic | Number of access paths, including administrative and service accounts | Test cases, sample of access events checked, and reporting format |
| Evidence upkeep | Internal compliance or security staff | Recurring, usually at each review cycle | Frequency of assessments, number of owners, and manual versus automated evidence collection | Which evidence is automated, who reviews log samples, and how often |
| Log review and alert handling | Internal security operations staff or a managed service provider | Recurring | Alert volume, tuning effort, and whether review is scheduled or ad hoc | Who performs review, review frequency, and escalation path |
| External review or testing | Independent assessors or testers | Periodic, tied to assessment cycles | Scope of the assessment and how many frameworks reference the same logs | Written scope, sampling approach, and whether a single set of evidence serves multiple frameworks |
| Auditor sampling | The organization pays the auditor or certification body for its work | Recurring at each audit | Sample sizes the auditor selects and the number of sensitive stores in scope | Auditor's sampling method and the evidence list they expect before fieldwork |
Who owns Safeguard 3.14 and what a partner can take on
Your organization owns the control. It decides which data counts as sensitive, which access events must be logged, how long audit records are kept and who acts on what the logs show. None of these decisions can be delegated to a vendor or partner, because the assessor will test whether the enterprise made and followed them.
- Data inventory ownership: Name the owner of each sensitive data set so the logging scope follows the inventory built under Safeguard 3.2 rather than a guess about where sensitive data lives.
- Log retention decisions: Set retention periods for access, modification and disposal records, and record the reason for each period in the data management process.
- Alert response: Assign people to review alerts from file integrity monitoring and access logs, define what triggers escalation and keep the tickets that show follow-up.
- Review routine: Schedule periodic reviews of logging coverage and of sample log entries, and keep the sign-off records as evidence.
Before an assessment, confirm that each decision has a named owner, a written date and a record of the review that approved it.
An implementation partner such as DeployOpen can prepare the systems that produce the logs and the evidence that shows them. The partner works inside your infrastructure on the platforms you run. The partner does not decide which events matter for your data, and it does not issue reports or certificates. Only an independent auditor or certification body does that.
- Logging configuration: Prepare audit settings for self-hosted platforms, for example the admin audit logging in Nextcloud, audit devices in OpenBao and monitored paths in Wazuh.
- Forwarding and evidence exports: Set up collection so audit records reach a central store with retention applied, and produce exports that an assessor can sample.
- Capture testing: Test that logs record read access, modification and disposal of sensitive data, using scripted test actions in a non-production environment, and document the results.
- Documentation: Write the configuration baseline, runbooks and test records that the enterprise reviews and adopts.
Fixed-scope work agreed in writing will name which platforms, environments and test cases are covered, so confirm that the scope includes disposal events and not only read access.
The auditor or assessor independently tests whether Safeguard 3.14 is in place. The test follows the measures in the CIS Controls Assessment Specification for Safeguard 3.14, which are combined into a coverage metric. The auditor selects samples, examines configurations and checks that logs exist for the events in scope. Its conclusion is its own.
- Specification-based testing: Expect checks against the five measures and the prerequisites for Safeguards 1.1, 2.1 and 4.1, which feed the data the measurement needs.
- Sampling of evidence: Expect requests for log samples covering access, modification and disposal, plus proof that retention and review were followed.
- Independence limits: A partner that designs the logging controls should not also present itself as the party testing them. The auditor will generally avoid relying on evidence it cannot separate from the designer's own work.
- Division of roles: Keep the partner in the preparation role and the enterprise in the ownership role, so the auditor tests a control your team operates.
Ask the auditor early which evidence it will accept and how it will treat partner-prepared material.
Where organizations fall short on sensitive data access logging
Safeguard 3.14 is only as good as the inventory, scope and review routine behind it. The gaps below recur across assessments, and each one leaves sensitive data access happening without a record that someone can later examine.
Sensitive stores missing from the inventory
A database, file share or SaaS workspace that is not in the data inventory is never selected for logging, so its access goes unrecorded by design. This undermines Safeguard 3.14 before any logging is configured. Check that the data inventory from Safeguard 3.2 lists every store that holds sensitive data, and tie each store to a named log source before you call the logging scope complete.
Reads logged, changes and disposal not
Many teams enable read logging on an application but leave writes, deletions and bulk exports unlogged. Safeguard 3.14 explicitly covers modification and disposal, so the events an attacker or insider most wants to hide are the ones that matter most. Test one record each for read, update and delete, then confirm each action appears in the log with the user, time and object identifier.
Logs kept only on the originating host
When audit logs stay on the server that produced them, an attacker with administrative access can alter or delete the evidence of their own activity. Centralizing sensitive data access logs to a separate store with restricted write access keeps the record intact. Confirm that the audit log path is forwarded off-host and that local copies cannot be edited by the same account that accesses the data.
No defined review or alert routine
Logs that no one reads satisfy collection but not detection, and Safeguard 3.14 sits in the Detect function for that reason. Assign an owner, define which sensitive data events trigger an alert, such as access by unexpected users or bulk reads, and record each review. Ask the team to show the last review record and the alert that followed it.
Service accounts excluded from logging
Automated jobs, integration accounts and service identities often read the most sensitive data, yet teams commonly exclude them from audit logging to reduce noise. Those accounts then become the least visible access path. Include every service account in the logging scope, label its events so they can be filtered, and review its access on the same schedule as human users.
Third-party data stores without log access
Sensitive data held by a SaaS provider or service provider is often outside the organization's own logs, with no contractual right to receive access records. Before relying on a provider, confirm in writing which access events it logs, how long it retains them and how you can export them. Align the answers with the data flows documented under Safeguard 3.8 and the provider terms under Control 15.
How much work Safeguard 3.14 takes and what to ask before hiring help
How much effort does Safeguard 3.14 take to implement?
The effort depends mostly on how well you already know where your sensitive data lives and which systems touch it. Safeguard 3.14 asks you to log access to sensitive data, including modification and disposal, so the work has three parts: deciding which data counts as sensitive, turning on and configuring logging on each system that holds it, and collecting and reviewing those logs. Teams that already maintain an asset inventory (Safeguard 1.1), a software inventory (Safeguard 2.1) and a documented secure configuration process (Safeguard 4.1) start with less discovery work, because the CIS Controls Assessment Specification names those three Safeguards as prerequisites for measuring 3.14. Where those inputs are missing, expect the first effort to go into building them. The measurement itself is five measures combined into one coverage metric, so you will need to show which sensitive data stores are logged and which are not.
How long does it take to log sensitive data access?
The timeline depends on the data inventory and the number of systems that hold sensitive data. A small set of applications with a current data inventory can be logged far faster than a estate of databases, file shares, SaaS tools and custom services with no inventory. Ask for the timeline to be tied to a named list of systems in the written scope, not to a general promise. Build the schedule around four checkpoints: sensitive data sources confirmed, logging enabled and tested on each source, log collection and retention set, and a first documented review cycle completed. Each checkpoint depends on the previous one, so a gap in the data inventory will delay everything after it.
Can we implement Safeguard 3.14 ourselves with open-source tools?
Yes, if you have engineering capacity to configure, operate and maintain the tools. Open-source platforms can produce much of the evidence Safeguard 3.14 needs. Nextcloud's admin_audit app writes additional event information to an audit log, OpenBao audit devices keep a detailed JSON record of API requests and responses, Wazuh file integrity monitoring alerts on creation, modification or deletion of monitored files, and Bareos Verify jobs compare files against cataloged attributes. Your team still has to decide what counts as sensitive, set the logging scope for each system, protect the log store and show that reviews happen. Confirm each tool's current logging options against its own documentation before you rely on it in your design.
What does the work need from our own staff?
The work needs four groups of people, and their time is usually the largest cost. Data owners must confirm which datasets are sensitive and who is allowed to access, modify or dispose of them. System administrators must enable logging, set log paths and permissions, and test that events are recorded. You need a log retention decision, which the documented data management process (Safeguard 3.1) and your legal or regulatory obligations should drive. Finally, you need a named review owner who checks sensitive data access logs on a defined schedule and records what was reviewed and what was done about anomalies. Assign these roles in writing before work begins, because an unowned review step is the most common reason logging exists but produces no evidence.
Will an auditor accept evidence we prepared ourselves?
The auditor decides whether your evidence is acceptable, and that decision is made against the framework your assessment uses, not against CIS alone. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, and only an independent auditor, assessor or certification body issues reports or certificates. Self-prepared evidence is common, such as log configuration exports, sample log entries, retention settings and review records. Whether it is sufficient depends on how the auditor tests it, how independent the preparer is and whether the records are complete and tamper-protected. Ask the auditor early which evidence they expect and how they want samples drawn.
What should a written scope include before we hire a partner?
A written scope should state exactly what the partner will do, what you will do and what each deliverable looks like. Include the named systems and sensitive data stores in scope, the logging events required for each (access, modification and disposal), the open-source tools to be configured, the log collection and retention design, the review procedure and its owner, and the evidence package to be handed over. Also record the prerequisites you will supply, such as access to systems, the current data inventory and named data owners. Add the acceptance criteria, the testing method and the handover format. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure and prepares systems and evidence for assessment, but it does not issue audit reports or certificates, and most engagements are fixed-scope with terms agreed in writing before work starts. A quote follows from that written scope.
Which costs recur after the initial Safeguard 3.14 work?
The one-time costs are discovery, configuration, testing and the first evidence package. Recurring costs come from operating the logs: storage and retention, periodic review, alert tuning, access to the log store and updates to the tools. Costs grow when the number of systems grows, when retention periods are longer, or when the sensitive data inventory changes often. Ask any partner to separate one-time and recurring items in the quote, and to state which tools need ongoing support. Ongoing support, upgrades and continuous testing are available as retainers from DeployOpen, and those terms should be written separately from the implementation scope.
How DeployOpen scopes and implements Safeguard 3.14 logging
DeployOpen helps your team build audit logging for access to sensitive data, including modification and disposal, inside your own infrastructure. The organization owns the Safeguard and its evidence, and an independent assessor decides whether the evidence meets the bar.
How we scope
- Confirm which sensitive data stores, applications and file shares fall under the logging requirement and the data inventory that defines them.
- Identify the prerequisite records for Safeguards 1.1, 2.1 and 4.1 and note any gaps before work starts.
- Agree the written scope, deliverables and timeline in writing before any work begins, since engagements are fixed-scope.
How we build
- Configure access and change logging on the chosen platforms, such as Nextcloud admin_audit, OpenBao audit devices or Wazuh file integrity monitoring.
- Set log destinations, permissions and time synchronization so entries are complete, tamper-resistant and attributable to a user or process.
- Test that reads, modifications and deletions of sensitive data each produce the expected log entry, and document the results.
How we hand over
- Deliver configuration records, a map of which sensitive data sources are logged, and the test results that show coverage.
- Document review and alerting procedures so your team can answer who accessed or changed sensitive data and when.
- Provide the evidence package the organization can present to its independent auditor or assessor, which DeployOpen prepares but does not certify.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover platform upgrades that change log formats, destinations or retention behavior.
- Ask us to confirm in writing which logging capabilities each chosen platform provides in your environment before scoping.
