What HITRUST audit logging and monitoring asks for, and why it fails
If an e1, i1 or r2 assessment is on your calendar, domain 12 is one you cannot leave to the end. Audit logging and monitoring is expected to work as a chain: the systems in scope generate events, those logs are protected from change and loss, someone reviews them on a defined schedule and records what they found, and the logs are kept long enough to support investigations. HITRUST groups the requirement statements for this chain under the 12 Audit Logging & Monitoring domain and scores it alongside the other 18. The risk the domain addresses is simple to state: without trustworthy logs, an organization cannot tell whether an intrusion, misuse or misconfiguration happened, and it cannot prove to an assessor that it would have noticed.
Why does it fail so often? The HITRUST 2025 Trust Report lists Audit Logging & Monitoring as 9.8% of failing domains in 2024, tied for second place. The pattern behind those failures is usually not missing tooling. The third most frequent corrective action plan asks organizations to define how often audit logs are reviewed, how each review is documented and who performs it. Many teams can show that logging is switched on but cannot show a dated, owned review routine with records behind it. Before the assessment, confirm the review cadence, the named reviewers and the form the review record takes for each in-scope system, then test that a sample of past reviews can be produced on request.
Scope is the second common gap. Decide which systems, administrative consoles and cloud accounts emit events into the assessed environment, and confirm whether any of them are provided by a third party whose logs you can only partly see. Where a provider generates platform events and you enable logging and analyze them in your own SIEM, the responsibility is split, and the split should appear in your shared responsibility documentation. Confirm the split with your assessor early, because an unclear boundary here tends to surface as a finding late in fieldwork.
Which systems, teams and third parties fall under domain 12
Domain 12 is only as large as the scope you define with your assessor, so the decisions below set most of the work. Each card covers one part of the in-scope environment, the team that runs it, or a boundary that changes who produces the evidence.
In-scope hosts and workloads
Every server, virtual machine and container that stores, processes or transmits in-scope data is a candidate for audit logging. Decide whether the scope follows the workload or the network segment, and record that choice in the scope statement. Check that each host type produces the events you expect, including ephemeral containers that may disappear before logs are collected. Ask the assessor to confirm how they will sample hosts during fieldwork.
Applications and their audit trails
Business applications often record user actions in their own logs, and those logs may not be enabled by default. For self-hosted platforms such as Nextcloud, the admin_audit app writes additional event detail to a log file that you must configure and protect. List each application, its log location and who can change its logging settings, so that gaps show up before the assessor finds them.
Databases and secrets stores
Databases holding in-scope data need logs covering administrative actions, schema changes and privileged queries. Secrets management systems need their own audit devices, because they record who requested which credential. OpenBao audit devices log every API request and response with most sensitive values hashed. Confirm the retention and storage location of these logs, since they often sit on separate infrastructure from the application.
Identity systems and cloud control planes
Directory services, single sign-on, and cloud administrative consoles and APIs are where privileged activity starts, so their logs carry high weight in domain 12. Include sign-in events, role assignments and changes to logging configuration themselves. Where a cloud provider generates platform events and you enable and analyze logs in your own SIEM, record that split in your responsibility matrix so the assessor can see who owns each event type.
Log pipelines and SIEM tooling
The collection, transport, storage and analysis path is itself in scope, because a log that is dropped, altered or never indexed does not satisfy the domain. Document each hop from source to SIEM, including forwarders, message queues and indexers. For detection platforms such as OpenSearch Security Analytics or Wazuh, the rules, alerts and dashboards they produce are evidence, so their configuration and access controls belong in scope too.
Administering teams and third parties
Name the teams who administer each in-scope system, including platform engineers, database administrators and security operations staff, and the outsourced managed service providers who run any part of the pipeline. Their activity is logged, and their log reviews must be defined and evidenced. Third-party-run systems also need contractual access to logs for the assessor. Confirm early whether AI security requirement statements added by the AI security certification place extra logging duties on any of these teams or systems, because scope decisions for AI systems are easier to settle before fieldwork.
Who owns logging when a cloud provider is involved
When systems run on a cloud provider, HITRUST's inheritance example for Oracle Cloud Infrastructure shows the usual division for this domain. The provider generates platform audit events for its own services, such as control plane activity. The customer must still turn on logging for the resources it runs, decide what to keep, and analyze the results, typically in a SIEM. Inherited results only count for the parts the provider actually covers, so the organization must evidence its own share.
- Provider-generated events: Platform audit records for the provider's infrastructure can be inherited when the provider's assessment covers them.
- Customer-enabled logging: The organization must switch on audit logging for its own accounts, virtual machines, databases and storage, since default settings often leave gaps.
- Log retention and protection: Copies in the customer's environment must be protected from alteration and kept for the period the organization sets.
- SIEM analysis: Reviews, alert tuning and documented review cadence are the organization's responsibility and cannot be inherited.
- Evidence of configuration: Screenshots, exported policies or configuration files showing logging is enabled in every in-scope account.
Confirm with the assessor which provider reports they will accept and which logging settings must be shown directly.
In a self-hosted environment, in the organization's own data center or an air-gapped network, there is no provider to inherit from. The organization generates, protects, reviews and retains every audit log itself. Open-source platforms can produce much of this evidence, but the organization must define the process around them. Air-gapped networks add the need to show how logs leave or stay inside the enclave and how time sources are kept consistent across hosts.
- Source logging: Each application, operating system, directory and network device in scope must emit logs, and the organization must document which ones do.
- Central collection: Logs from isolated segments need a defined path to a central store, with transport protection and integrity checks.
- Platform audit trails: Tools such as OpenBao keep detailed JSON audit devices, and Nextcloud's admin_audit app writes audit entries to a file, but both must be enabled and their output retained.
- Detection and review: A platform such as Wazuh or OpenSearch Security Analytics can match events against rules, but someone must be named to review alerts on a stated schedule.
- Retention records: Written retention periods and proof that old logs are deleted or archived as planned.
Confirm how the assessor expects air-gapped log transfers and offline review to be evidenced.
Many organizations run some workloads in a cloud provider and keep others on premises or in an air-gapped network. Logging ownership then has to be drawn for each environment separately, and the boundary between them needs an owner. The most common failure is a gap where neither side collects the events, each assuming the other does. Central monitoring across both sides is useful, but it does not transfer ownership of the cloud-side events to the on-premises team.
- Environment-by-environment map: Each system in scope is assigned to the cloud or self-hosted model, with the logging owner named.
- Boundary events: Connections between cloud and internal networks, such as VPN, interconnect or identity federation logs, need a clear owner.
- Consistent review: One review process should cover both sides, or each side needs a documented review with the same cadence.
- Inheritance limits: Provider results apply only to the cloud-hosted portion, so the on-premises portion must stand on its own evidence.
- Shared responsibility matrix: A single matrix that lists each logging control, the owner and the evidence location.
Confirm the hybrid split in the shared responsibility matrix with the assessor before fieldwork begins, since the matrix sets what can be inherited.
How an assessor tests audit logging and monitoring
This table sets out how an external assessor typically tests each part of the audit logging and monitoring domain, what evidence the assessor asks for, and where organizations most often fall short. Read each row as a question the assessor will ask of your own controls, not of a tool. The main takeaway is that the assessor examines whether logging and review operate as written over the assessment period, and HITRUST performs quality assurance before any report is issued.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Sampling of configured log sources | Inventory of in-scope systems with logging status, configuration exports for each sampled source, and the scope boundary the organization documented | Log sources in the scope inventory that are not sending events to the central pipeline |
| Walk-through of log generation | Live or recorded demonstration of event creation for authentication, administrative and data access actions, plus the configuration that enables it | Logging turned on for some systems but not for privileged or administrative actions |
| Protection of log integrity | Access lists for log stores, evidence that logs cannot be altered or deleted by ordinary administrators, and records of any changes to logging settings | Administrators able to edit or disable logging with no alert or recorded approval |
| Review cadence and reviewer | Documented review frequency, named reviewers or roles, and review records with dates for the assessment period | Review frequency never defined, or reviews performed informally with no owner named |
| Documentation of review outcomes | Review records showing what was checked, findings raised, and how each finding was closed or escalated | Reviews performed but no documented outcome, so the assessor cannot confirm the review happened |
| Retention settings | Configured retention periods for each log store, backup or archive settings, and the retention rule the organization approved | Retention set in one tool but not in the central store, or no documented rationale for the period |
| Alert handling | Alert rules in force, samples of triggered alerts, tickets or case records showing triage and closure | Alerts generated but not triaged, or closed without evidence of investigation |
| Sampling of review and alert records | Assessor-selected samples across the period, checked for completeness and timeliness against the documented cadence | Gaps in the sample period where no review or alert record exists |
How to implement domain 12 in order
This sequence takes audit logging and monitoring from an unknown set of log sources to a documented, repeatable review that an assessor can test. Each step produces an artifact the assessor will ask to see, so the work is done in the order the evidence depends on it.
Inventory every in-scope log source
Start by listing every system, application, cloud service, network device, identity provider and administrative tool that touches the in-scope environment. Record the owner, the log types each source produces and whether the organization or an inheritance provider controls it. Where the provider generates platform events and the organization must enable logging and analyze it, mark that split explicitly. The step closes when the inventory is signed off by the system owners and matches the assessment boundary.
Write the logging standard
Define the minimum content each log event must carry, such as the actor, action, target, timestamp, outcome and source address, and which events are mandatory for each source type. Set one time source for all systems and document how clocks are synchronized and monitored. Specify which sensitive values must never be written to logs. The step closes when a written standard exists, is approved by the owner of the domain, and the inventory shows which sources already meet it and which need configuration changes.
Centralize and protect the logs
Route log events from every in-scope source into a central store that the application teams cannot silently edit. Define who can read, write and delete logs, separate log administration from the systems being logged where practical, and record access to the log store itself. Draw the pipeline as a diagram showing sources, transport, storage, access points and any inheritance boundary. The step closes when the diagram matches the running configuration and a test event from each source is visible in the central store.
Define the review cadence and named reviewers
Write a review procedure that states what is reviewed, how often, by which named role and person, and what evidence the reviewer leaves behind. Separate routine review from event-driven review of alerts, and state the backup reviewer for absences. HITRUST's 2025 Trust Report found that defining how often logs are reviewed, how reviews are documented and who performs them was among the most common corrective action plans, so this document carries real weight. The step closes when the procedure is approved and each reviewer has accepted the responsibility in writing.
Configure alerting and escalation
Turn the logging standard into detection rules for the events the organization must act on, such as failed privileged logins, changes to logging settings and access to sensitive data. Route each alert to a named queue, set severity levels, and define the escalation path into the incident management process. Confirm that someone can be reached outside normal hours if the escalation path requires it. The step closes when a test alert reaches the named queue and a ticket follows the escalation path end to end.
Set the retention schedule
Document how long each log category is kept online and in archive, where archives are stored, how they are protected from alteration, and how they are deleted when the retention period ends. Align the schedule with contractual, regulatory and internal obligations, and record who approved each period. Confirm that the schedule works with the data protection and privacy requirements for the same records, since logs often contain personal data. The step closes when the retention schedule is approved and a sample restore from archive has been performed and recorded.
Run a dry-run review before the assessment window
Before the validated assessment begins, have the named reviewers perform the review procedure for a full cycle, using the real logs and recording the evidence as the procedure requires. Ask an internal person who did not write the procedure to check whether the records show what was reviewed, by whom, when and with what result. Fix gaps in the procedure, the reviewer assignments or the records, then keep the dry-run records as the first evidence set. The step closes when the assessor's likely sample requests can be answered from existing records without reconstruction.
What meeting domain 12 costs in money and effort
This table breaks the cost of meeting Audit Logging & Monitoring into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to frame a quote request, since no price is estimated here and the real figure depends on your own scope.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Software vendor or subscription provider; open-source projects charge no license fee | Recurring if commercial; one-time setup for open source | Commercial log platforms often price by ingested volume or hosts. Open-source options such as Wazuh or OpenSearch remove license spend but not hosting or support needs. |
| Engineering time to configure log sources | Internal platform engineers or an implementation partner under a written scope | One-time, with later changes | Number of in-scope sources (hosts, databases, cloud services, applications, identity systems) and how many use different log formats. |
| Pipeline and storage | Your cloud or data center provider, and whoever runs the storage platform | Recurring | Log volume, retention period and whether logs must be kept immutable. Longer retention and verbose application logging raise storage and search costs. |
| Alert rules and detection tuning | Security engineers, internal or partner | One-time build, then recurring tuning | Number of detection rules, noise from false positives, and how often new services or threats require new rules. |
| Recurring log review effort | Internal security operations staff who perform and document reviews | Recurring | Review frequency, number of reviewers, alert volume and the depth of documented follow-up. Staffing is often the largest ongoing item. |
| Evidence upkeep | Compliance lead, control owner and system administrators | Recurring | Frequency of evidence collection, number of systems sampled at assessment and how cleanly review records are kept for the assessor. |
| External readiness or testing support | Implementation partner or consultant under a fixed-scope agreement | One-time before assessment, sometimes repeated | Gaps found in readiness testing, the number of log sources needing remediation and whether the scope includes AI security requirements. |
| Assessor fieldwork | Authorized HITRUST External Assessor, paid by the organization | Recurring at each validated assessment | Assessment scope, number of sources and records sampled, and the number of requirement statements in domain 12 that the assessor tests. |
Which open-source tools produce domain 12 evidence
Domain 12 asks for logs that are generated, protected, reviewed and retained, so the tools you choose must produce records an assessor can sample. The four components below each cover a different layer: application actions, secrets access, log analytics and host-level event detection. None of them decides how often your team reviews logs, so confirm how each output maps to your own review procedure before the assessment window opens.
Nextcloud admin_audit logging
The bundled admin_audit app records administrative and security-relevant events in Nextcloud and writes them to audit.log in the data directory by default. You can point the output elsewhere with the logfile_audit setting, which matters when logs must leave the application host for protected storage. Check that the file location, permissions and rotation match your retention rule, and confirm that the events you need, such as permission changes and file access on in-scope data, are actually captured in your configuration. Licensed under AGPL-3.0-only.
OpenBao audit devices
OpenBao audit devices write a detailed JSON record of every API request and response, including errors, which gives you a complete trail of secret and policy access. Most sensitive values are hashed with HMAC-SHA256 before they are written, so the log can be reviewed without exposing the secrets themselves. Decide which audit device paths are enabled, where they write, and how a failed device is handled, because a request can be blocked if no audit device is working. Licensed under MPL-2.0.
OpenSearch Security Analytics
Security Analytics detectors match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match becomes a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. The correlation engine links findings across log types in a correlation graph, which helps reviewers trace one event across systems. Confirm which log sources feed the detectors, who tunes the rules, and how findings are closed and documented. Licensed under Apache-2.0.
Wazuh alerts and ruleset
Wazuh decodes collected logs and compares each event against more than 3,000 built-in rules and decoders plus any custom rules you add. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. Assessors will look for evidence that agents cover in-scope hosts and that alerts are reviewed on a defined schedule, so confirm agent coverage and the review record. Licensed under GPL-2.0-only.
What evidence passes review and how to keep it current
Assessors test domain 12 by asking for a set of evidence families that show logs are generated, protected, reviewed and kept. Start with a log source inventory that names every system in the assessed scope that produces audit events, such as the identity provider, the application servers, the database tier, the hypervisors and the cloud control plane, together with the owner of each source. Pair the inventory with logging configuration exports: for example, the admin_audit app settings and the logfile_audit path in Nextcloud, the audit device configuration in OpenBao, and the forwarding rules in your SIEM. Then add sample log extracts that show the events the requirement statements call for, such as privileged logins and changes to access rights, with timestamps and user identifiers intact. Each sample should be traceable back to its source in the inventory. Finally, include the written review procedure, which must state what is reviewed, how often and by whom, and the retention settings that show how long logs and alerts are kept. Confirm the exact retention periods your own policy and any contractual or regulatory obligations require, since the assessor will compare the configured value with the written one.
The evidence that most often fails is the review record, so treat it as a dated artifact rather than a summary. Each review should carry the date, the reviewer, the sources and time window covered, the findings, and the disposition of each finding. Alert and escalation tickets linked from those records show the review produced action. Where a Wazuh, OpenSearch or other detection tool generates alerts, export the rule set version and a sample of alerts.json or Security Analytics findings for the same period so the review can be matched to what the tool actually raised. To keep this current between assessments, schedule the configuration exports and log source inventory refresh on a fixed cadence, retain every signed review sign-off in your evidence repository, and record each change to a log source (a new system, a disabled audit device, a changed retention value) with its date, approver and reason. Illustrative example: if a new database cluster goes live without forwarding, the change record and the next review should show it was found and fixed. Ask your assessor to confirm which sampling period and format they will accept before you build the process.
Where organizations usually fall short on domain 12
Audit logging and monitoring gaps rarely come from missing tools. They come from undefined review cadence, unproven coverage, and logs that no one can show were protected or kept long enough. The cards below name the gaps assessors most often find in domain 12 and the concrete steps that close each one.
No defined review frequency
Many organizations collect logs but never write down how often anyone reviews them. HITRUST's 2025 Trust Report lists a corrective action plan asking organizations to define how often audit logs are reviewed, how reviews are documented and who performs them. Write a logging standard that sets a review cadence for each log source, names the role responsible, and states the escalation path when a review finds something. Ask the assessor which cadence they expect to see tested against your own records.
Reviews performed but not documented
A reviewer may check a dashboard every morning, yet leave no record that the check happened. Assessors test the review, not the intention, so a review without a dated record, a named reviewer and a noted outcome is hard to evidence. Use a ticket queue, a SIEM case or a signed review log entry for each review cycle. Record what was examined, what was found, and what was closed or escalated. Confirm that the record can be produced for the full assessment period.
Incomplete log source coverage
Logging is often enabled on the core application but not on the database, the identity provider, the bastion host or the admin console. Gaps appear when new systems join the in-scope environment without a logging step in their onboarding. Build a register of in-scope systems and map each one to its log source, its destination and its owner. Review the register at each change to scope, and compare it against asset inventory during readiness work.
Logs writable by administrators
If the same administrators whose actions are logged can edit or delete those logs, the record loses its value as evidence. Protect logs by forwarding them off the originating host to a separate store with restricted write and delete rights, and by logging access to the log store itself. For secrets management platforms, enable an audit device so every API request and response is recorded, and confirm that sensitive values are hashed rather than stored in plain text.
Retention shorter than policy
An organization may set a retention period in its policy but configure its log store to rotate files sooner. When a security event is investigated months later, the logs have already been deleted, and the policy becomes a finding. Compare the configured rotation and archive settings on every log source against the retention period in your policy. Ask your assessor how they will sample retained logs across the assessment period, and keep the configuration evidence that shows the setting applied.
Inherited cloud logging assumed
HITRUST's inheritance example treats this domain as moderately inheritable: the cloud provider generates platform audit events, while the customer must enable logging and analyze the logs in its own SIEM. Teams often assume the provider covers everything. Check the shared responsibility matrix line by line, confirm which events the provider logs, and confirm that the customer has turned on the relevant logging and monitoring. Any gap in that split should be documented as a customer responsibility with evidence.
Who does what: your team, a partner and the auditor
Your organization owns the audit logging and monitoring controls, so accountability for them cannot be handed to a partner or an assessor. Control owners decide what gets logged, how long logs are kept and who reviews them. Security operations runs the review and alerting routine, and system administrators enable logging on the platforms in scope and keep those settings from drifting.
- Control owners: define the logging standard, the review frequency, the reviewer roles and the retention period, and approve exceptions.
- Security operations: triage alerts, record review outcomes and escalate events into incident management.
- System administrators: enable audit settings on applications, operating systems, databases and cloud accounts, and protect log files from change.
- Application and platform owners: confirm which events their systems must emit and which fields a reviewer needs to act on them.
- Records and evidence owners: keep dated review records, sign-offs and log samples that an assessor can sample.
Before relying on any partner, confirm internally who signs off on the review cadence, since assessors look for a named owner and documented review, not only a tool that logs.
An implementation partner helps you prepare systems and evidence for the assessment. DeployOpen, for example, plans, configures and documents self-hosted open-source platforms inside your own infrastructure. A partner does not decide your control design, does not issue reports, and does not certify anything. Their work is mostly one-time setup plus whatever support you retain afterward.
- Scoping support: identify which systems, accounts and log sources fall inside the assessed environment and which are inherited from a provider.
- Pipeline configuration: set up log collection, detection rules and alert routing in platforms you own, such as a SIEM or audit log store.
- Evidence preparation: document log coverage, retention settings, review records and access to log stores in a form an assessor can sample.
- Dry-run reviews: test whether a sample of events can be traced from source to alert to documented review before the assessor arrives.
- Documentation and handover: leave runbooks and configuration records that your staff can maintain after the engagement.
Scope, deliverables and timelines are agreed in writing before work starts, so ask any partner to state exactly which of these items are in the quote and which remain with your team.
Only Authorized HITRUST External Assessor organizations can perform the validated assessments submitted for certification, and HITRUST performs central quality assurance before it issues reports. The assessor tests your controls against the requirement statements in this domain, samples evidence within a fieldwork window of up to 90 days, and reports the results. Your organization does not choose the assessor's conclusions, and neither does the implementation partner.
- Testing: inspect logging configuration, retention settings and access controls on log stores.
- Sampling: select review records and events across the period in scope and check that reviews happened at the documented frequency.
- Interviews and walkthroughs: confirm with reviewers who performs reviews, how findings are escalated and how exceptions are handled.
- Scoring and reporting: score the domain and record any gaps, which become corrective action plans where needed.
- Independence: the assessor must remain independent of the team that prepared the evidence.
Before engaging an assessor, confirm on the HITRUST find-an-assessor listing that the firm is authorized for the assessment type you need.
Questions buyers ask about domain 12 before hiring help
How much effort does HITRUST domain 12 take, and what drives it?
Effort depends mostly on how many systems are in scope, how much of their logging already exists, and how well the organization can show that logs are reviewed. No supplied figure gives a standard effort estimate, so ask for one in writing. A quote should break the work into logging configuration, log retention and protection, SIEM or monitoring deployment, review procedures and evidence collection. Each component should list the systems it covers and who performs it. Environments with many applications, multiple cloud accounts or unmanaged legacy systems usually need more time than a small, single-platform scope. Ask the implementer to name the assumptions behind its estimate so you can test them against your own inventory.
Can our team prepare domain 12 without an outside partner?
Yes, an internal team can prepare domain 12 if it has engineers who can configure logging and monitoring, and staff who own the review process. Outside help is most useful for the parts that are easy to get wrong: defining what must be logged for each in-scope system, setting a review frequency that matches the risk, and producing evidence that an assessor can trace. Remember that only an independent HITRUST External Assessor organization performs the validated assessment, and HITRUST performs quality assurance before issuing reports. A partner prepares systems and evidence but does not issue the report. Decide which tasks your team owns before asking anyone to take on the rest.
How long does domain 12 work take compared with the 90-day fieldwork window?
The assessor's validated fieldwork window is at most 90 days for e1, i1 and r2 assessments. Domain 12 work normally happens before fieldwork starts, so the question is how long it takes to get logging and review in place and running long enough to show evidence. Assessors need to see that controls operated over a period, not only that they were configured on the day of testing. Ask the implementer to plan the work against your fieldwork date, and to identify which controls need an operating history before the assessor arrives. No duration figure is supplied here, so request a schedule tied to your own assessment timeline.
What does domain 12 need from our engineers, administrators and reviewers?
The work needs three groups of people. Platform and application engineers enable and protect audit events, set retention, and keep log sources feeding the monitoring tool. Security operations staff define detection rules, triage alerts and document reviews. Control owners decide how often logs are reviewed, who performs each review, and how the review is recorded. The third group is often the gap. HITRUST's 2025 Trust Report lists defining review frequency, documentation and reviewers among the most common corrective action plans in this domain, so name a reviewer and a cadence early. Ask any partner to show how they will train your staff to run those reviews after the engagement ends.
Does inherited cloud logging count toward our domain 12 requirements?
Inheritance can cover part of domain 12, but not all of it. HITRUST's inheritance example describes this domain as moderately inheritable: the cloud provider generates platform audit events, while the customer enables logging and analyzes logs in its own SIEM. That means provider evidence supports the platform layer, and your organization still owns log configuration, retention for its own data, and review. Confirm the exact boundary in the shared responsibility matrix before relying on it. Ask whether the provider's HITRUST results cover the specific services you use, and whether any monitoring you rely on sits outside the provider's report.
How do AI security requirements change the domain 12 work?
HITRUST's AI Security Assessment help page places AI security requirement statements in this domain, so an e1, i1 or r2 with the AI security certification adds requirements here. In practice, you would need to show that AI systems and agents in scope generate logs, that those logs are retained and protected, and that someone reviews them. Logging of prompts, tool calls and model access may need design decisions about sensitive data. Confirm with the assessor and the HITRUST documentation which AI requirement statements apply to your scope, and ask any implementer to list them in the quote as separate line items.
How DeployOpen scopes and prepares domain 12 evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, including the logging and monitoring that domain 12 evidence depends on. We prepare the systems, log sources and records an assessor will sample, while your organization keeps ownership of its controls and an independent HITRUST External Assessor issues the report.
How we scope
- We agree in writing which in-scope systems, applications and log sources fall under domain 12 before work starts.
- The written scope names who reviews logs, how often reviews happen and where review records will be kept.
- We confirm with your assessor which inherited provider logging, such as platform audit events, is already covered by their evidence.
How we build
- We enable audit logging in the in-scope platforms, such as the admin audit events of Nextcloud and the request logs of OpenBao audit devices.
- We configure central collection and detection rules in a SIEM such as Wazuh or OpenSearch Security Analytics, tuned to your scope.
- We protect log integrity and retention settings so that logs cannot be silently altered or deleted by ordinary administrators.
How we hand over
- We document the logging standard, review cadence and reviewer roles so each one maps to a specific control statement.
- We deliver sample evidence packs, such as alert exports and review sign-offs, that your team can walk an assessor through.
- We test the logging configuration and record results, then hand over runbooks so your staff can operate the setup independently.
How we support
- Fixed-scope engagements end with agreed deliverables, and any further work is quoted from a new written scope.
- Ongoing support, upgrades and continuous testing of the logging stack are available as a retainer.
- Before any assessment fieldwork, confirm with your assessor which log review evidence they will sample and for what period.
