Satisfying CMMC Level 2 Audit and Accountability Controls with tiCrypt

If you are preparing for a CMMC Level 2 assessment, the Audit and Accountability (AU) control family is one of the first areas an assessor will examine. The nine AU practices in NIST SP 800-171r2 (practices 3.3.1 through 3.3.9) require your organization to demonstrate that every action involving Controlled Unclassified Information (CUI) is logged, attributable to a specific user, protected from tampering, and available for review. tiCrypt's audit system addresses these requirements.

This article is written for compliance officers and audit program managers building a System Security Plan (SSP) and preparing evidence packages for CMMC Level 2 assessment. It covers what tiCrypt's audit system captures and flags, how the architecture works and connects to your SIEM, where the platform's responsibility ends and your organizational controls must begin, and how each AU practice maps to specific capabilities and evidence. For a deeper look at the audit schema and forensic investigation capabilities, see Usage Reporting and Forensics in tiCrypt Audit.

What tiCrypt Logs Natively

tiCrypt's audit system is not an optional module. It is a structural component of the platform that is always active. Every operation within the enclave produces a structured audit record, whether initiated by a user, an administrator, or a system process. There is no configuration flag to enable or disable logging, and no class of action that bypasses the audit pipeline. From an assessment perspective, this means your SSP can state that audit logging is mandatory and cannot be circumvented by any user or administrator.

The audit schema defines over 150 distinct event types across every layer of the platform:

Category	Examples	What Is Captured
Authentication and sessions	Login, logout, session creation, MFA challenge, session downgrade, permission grant	User identity, source IP, MFA token, granted actions, session duration, expiration
File operations	Creation, deletion, chunk-level reads and writes, encryption key retrieval, ownership transfer	Session context, file ID, key type, key owner, intent (why the key was accessed)
Directory operations	Entry addition, removal, rename, root assignment, project tagging	Directory ID, entry name, entry type, target, path context
Data uploads and downloads	Chunk-level transfers, drive byte-level transfers, file retrieval	Transfer ID, byte count, object identifiers, direction, ownership chain
Sharing activities	Group membership changes, permission modifications, project access grants, security level assignments	Acting session, affected entity, old and new values, expiration tracking
Virtual machines	Creation, shutdown, deletion, proxy registration, configuration changes, authorized user changes	VM ID, VM Hardware Setup template, host, initiating user, configuration details
Drives and storage	Creation, attachment, detachment, deletion, key operations	Drive ID, object identifiers, ownership chain
Encryption key management	Key escrow creation, public key registration, key generation, recovery key creation, key retrieval	Authentication type, authorizer identity, cryptographic parameters, key type, key owner
Data ingress	Form creation, token-based and session-based submissions, attachment reads	Submission source, form metadata, key operations
System administration	Settings changes, MFA token creation, maintenance operations, service restarts, device management	Administrative action type, parameters, affected scope

Every event in every category produces a record. The system does not aggregate, downsample, or summarize. This is the behavior required by CMMC L2 practice AU.L2-3.3.1 (NIST 800-171r2 practice 3.3.1): creation and retention of system audit logs sufficient to support monitoring, analysis, investigation, and reporting.

Real-Time Alerts and Dashboards

The logging system captures all events; the alert system flags the ones that require attention. tiCrypt generates real-time alerts for audit processing failures (as required by CMMC L2 practice AU.L2-3.3.4) and for additional security-relevant events.

Alert types

Alert	Severity	What It Detects
IP Alert	High	Login from an unusual location, or two logins separated by an implausible geographic distance in a short time window
Hash Alert	Critical	The SHA-256 audit chain has been broken, indicating possible tampering with the log
User Locked	Medium	An account has been locked due to failed authentication attempts or administrative action
User Added	Low	A new account has been created
State Changed	Medium	A user account state has changed (activated, deactivated, suspended)
Role Changed	High	A user's role or permissions have been modified
File Downloaded	Info	A file has been retrieved from the secure environment
XSS Detected	Critical	A cross-site scripting attempt has been identified

Each alert carries a severity rating (Info, Low, Medium, High, Critical) and is delivered through all configured drivers simultaneously. The audit interface provides severity-based filtering and user-based filtering for alert triage.

Geolocation and Impossible-Travel Detection

When a GeoIP2 database is configured, tiCrypt Audit resolves source IP addresses to geographic coordinates. This enables the IP Alert to detect impossible-travel scenarios: if a user logs in from New York at 14:00 and from Tokyo at 14:15, the system flags the anomaly. Alert records include latitude, longitude, accuracy radius, city, and country for both the current and previous login.

Reporting and compliance dashboards

tiCrypt Audit provides three tiers of reporting capability, each designed for a different operational role.

Pre-built compliance reports. Scoped by time range and optionally by object (user, team, project, VM, or file). Output is .xlsx with charting and column statistics (distinct values, total, min, max, mean, median, standard deviation). These reports map to the documentation that CMMC L2 assessors evaluate during AU practice verification. When an assessor requests evidence for practices 3.3.1 through 3.3.6, these reports are the relevant output.

Report types include:

• Global reports: System-wide activity summaries, authentication patterns, administrative actions
• Per-project reports: All file access, membership changes, and VM activity within a specific project
• Per-user reports: Complete activity history for a single user across all projects and resources
• Per-team reports: Team membership changes, permission modifications, resource usage

Parameterized queries. Built-in queries accept configurable parameters: strings, numbers, date ranges, success/failure filters, and autocomplete fields for users, teams, and projects. Results display in sortable columns with column statistics and data-type-specific rendering. Rendered formats include formatted numbers, human-readable file sizes, and clickable object IDs that link to detail views. Query results can be visualized as line charts, bar charts, pie charts, or geographic maps. Any result set can be exported to Excel.

Object inspection. Every entity in the audit system (users, teams, projects, files, drives, VMs, IP addresses) has a detail view that shows its full metadata and history. Clicking an object ID in any query result opens the inspection view for that object, enabling rapid navigation during investigations.

Anatomy of an Audit Record

Each audit record is a structured object with consistent fields that support filtering, correlation, and forensic reconstruction. The level of detail captured within each record is important for both compliance and investigation:

• Timestamp: Millisecond-precision UTC timestamp, synchronized to NTP. All records across all components share the same time source.
• Event type: A two-character code identifying the specific operation (e.g., FG for file key retrieval, FR for chunk-level read, GA for group member addition, UM for role change).
• User identity: The authenticated user who performed the action, tied to a cryptographic identity.
• Session context: The authenticated session under which the action was performed, linking the event to a specific user identity, source IP, and authentication method.
• Source IP address: The network address from which the action originated.
• Success or failure indicator: Every event records whether the operation succeeded or failed, with an error code when applicable.
• Action-specific attributes: Structured fields relevant to the event type. A file key retrieval records the file ID, key type, key owner, and access intent. A session creation records the granted permissions, expiration time, and MFA token used.
• Version field: Schema version for backward compatibility as the audit format evolves across tiCrypt releases.
• Hash chain position: Each record's SHA-256 hash incorporates the hash of the previous record, creating a tamper-evident chain.

Together, these fields allow any event to be attributed to a single authenticated user, a precise time, a network location, and a specific operation with its outcome. This is what NIST SP 800-171r2 practice 3.3.2 (CMMC L2 practice AU.L2-3.3.2) requires: the ability to trace actions to individual users. When an assessor asks for evidence of individual accountability, these records are the relevant artifact.

Log Retention: Lifetime of the System

tiCrypt retains all audit records for the lifetime of the deployment. There is no retention window, no rotation policy, and no purging schedule. Logs are never deleted. Retention is not configurable. There is no setting to shorten or limit the retention period. From a compliance standpoint, this removes the possibility of gaps in the audit trail due to retention policy expiration.

For reference, here are the applicable retention requirements:

Requirement	Minimum Retention	tiCrypt Retention
DFARS 252.204-7012	90 days from incident report submission	Lifetime of deployment
NIST SP 800-171r2 (3.3.1)	Sufficient to support monitoring and investigation	Lifetime of deployment
CMMC Level 2 (AU.L2-3.3.1)	Create and retain system audit logs	Lifetime of deployment

Audit logs are structured, repetitive data that compresses extremely well. ClickHouse's column-oriented storage reduces the on-disk footprint to a fraction of the raw log size. The complete audit history of a multi-year production deployment typically occupies tens of gigabytes. The small storage footprint means there is no practical pressure to discard records. Organizations should always save and back up their audit data as part of their standard data protection procedures.

Query performance remains sub-second across large datasets, so growing log volume does not degrade usability for investigators or assessors.

For organizations with data sovereignty requirements, tiCrypt Audit stores all data locally on the audit server. No audit data is transmitted to external cloud services. The ClickHouse database resides on infrastructure the organization controls.

Architecture and Tamper Resistance

The sections above describe what tiCrypt's audit system captures and how it surfaces that information. This section and the next cover how the system is built and how it connects to your security operations infrastructure.

tiCrypt Audit is architecturally separated from the tiCrypt backend. This separation is the basis of the system's integrity guarantees and is directly relevant to CMMC L2 practices AU.L2-3.3.8 (protecting audit information) and AU.L2-3.3.9 (limiting management of audit functionality).

One-way data flow

The tiCrypt backend pushes log entries to tiaudit-logger over TCP port 25000. The audit system has no return path to the backend. It cannot send commands, modify data, or influence the backend's operation. Compromising the audit system does not grant access to the production environment. Compromising the backend does not grant write access to the audit database.

Independent operation

tiCrypt Audit consists of three independent components:

1. tiaudit: Hosts the web interface and reporting engine
2. tiaudit-logger: Receives log entries from the backend, validates the hash chain, and inserts records into ClickHouse
3. tiaudit-log-uploader: Backfills historical logs during initial deployment or recovery

Multiple independent audit installations can consume the same log stream from a single backend. An organization can deploy a primary audit server for day-to-day operations and a secondary instance on a separate network segment for independent verification.

Hash chain protection

Each audit record is hashed with SHA-256, incorporating the hash of the previous record. Any modification, insertion, or deletion of a historical record invalidates all subsequent hashes. The chain can be verified programmatically at any time. A break in the chain pinpoints the exact record where tampering occurred.

This mechanism provides:

• Tamper evidence: Modifications are detectable automatically
• Non-repudiation: Actions tied to cryptographic identities cannot be plausibly denied
• Independent verification: Any party with read access to the audit database can verify the chain without relying on the backend

SIEM Integration

CMMC L2 practice AU.L2-3.3.5 (NIST 800-171r2 practice 3.3.5) requires the ability to correlate audit review, analysis, and reporting processes. In practice, assessors expect to see audit data flowing into your SIEM, where it can be correlated with events from other systems in your CUI boundary. tiCrypt provides four mechanisms for delivering audit telemetry to external security platforms. These are not mutually exclusive; a deployment can use all four simultaneously.

Alert drivers (push)

tiCrypt Audit includes configurable alert drivers that push security-relevant events to external systems in real time. Three driver types are supported:

Splunk driver. Pushes JSON-formatted alerts directly to a Splunk HTTP Event Collector (HEC) endpoint. Configuration parameters include the collection URL, authentication token, source name, source type, index, and TLS certificate verification settings. The alert payload is structured JSON, ready for Splunk indexing without additional parsing.

[drivers.splunk-prod]
type     = "splunk"
disabled = false
url      = "https://splunk.example.com:8088/services/collector"
token    = "your-hec-token"
source   = "tiCrypt"
sourceType = "tiCryptAlert"
index    = "main"
certified = true

Email driver. Sends alert notifications over SMTP with configurable recipients (to, cc, bcc), retry logic, and TLS support. Suitable for security teams that triage alerts through email or ticketing systems.

Console driver (log file output). Outputs structured alert data to a log file via stdout or stderr. This is a general-purpose ingestion path for any SIEM platform. The log file can be consumed by LogRhythm, QRadar, Elastic, Microsoft Sentinel, or any other tool that reads structured log files. Use systemd journal forwarding, a syslog relay, or a file-based collector (such as Filebeat, Fluentd, or a native SIEM agent) to ingest the console driver's output. This is the recommended path for non-Splunk SIEM deployments.

Ingestion paths by SIEM platform

SIEM Platform	Recommended Ingestion Path
Splunk	Splunk HEC driver (native push)
LogRhythm	Console driver log file via LogRhythm System Monitor agent
IBM QRadar	Console driver log file via syslog forwarding, or REST API polling
Elastic / OpenSearch	Console driver log file via Filebeat, or REST API polling
Microsoft Sentinel	Console driver log file via Azure Monitor Agent, or REST API via Logic App
Other platforms	Console driver log file (any file-based collector), REST API, or HEC-compatible endpoint

Your SSP should document which integration method you selected and confirm that tiCrypt audit data is flowing into the same SIEM instance that handles the rest of your CUI boundary monitoring.

REST API (pull)

The tiCrypt Audit REST API provides token-based programmatic access to the full audit dataset. API tokens are generated through the audit interface and authenticate via an x-access-token HTTP header.

Available endpoints:

Endpoint	Method	Returns
/alerts/{start}/{end}	GET	All alerts triggered in a date range
/queries/{queryID}/{endDate}	POST	Results of a parameterized query
/reports/{reportID}/{start}/{end}	GET	Generated Excel report
/objects/{type}/{endDate}	POST	Object metadata (users, teams, files, VMs, IPs)
/queries/list	GET	Available queries with parameter schemas
/reports/list	GET	Available reports with scoping options
/alerts/list	GET	Alert type definitions with severity levels

The API enables automated compliance workflows. A scheduled job can pull weekly reports, a SIEM connector can poll for new alerts, and custom tooling can query the audit database for specific investigation needs. Dates use YYYY-MM-DD format. Query parameters support filtering by user, team, time range, event type, and success or failure status.

Direct SQL access

For ad-hoc forensic analysis beyond what pre-built queries and reports cover, tiCrypt Audit exposes direct SQL access to the ClickHouse database. ClickHouse is a column-oriented analytics engine optimized for the queries audit work demands: filtering millions of records by time range, user, event type, or object ID. In practice, queries across datasets spanning millions of records complete in one to two seconds.

Direct SQL access supports complex forensic investigations, custom dashboard construction, and integration patterns that the REST API does not cover directly. During assessment preparation, this access allows generating custom evidence artifacts for specific practices.

Shared Responsibility

tiCrypt audits what happens inside the enclave at the application level. It has no visibility into hardware telemetry, operating system events, or network-layer activity. Your SSP must clearly document what the platform handles, what your organization handles, and how the two connect.

Audit responsibility matrix

The table below clarifies which audit responsibilities the platform covers, which belong to your infrastructure team, and which are shared.

Audit Domain	tiCrypt Platform	Organization Infrastructure	Notes
User authentication	Logs all login/logout, MFA, session events	N/A	tiCrypt is the authoritative source
File access and transfers	Logs all reads, writes, uploads, downloads, key retrievals	N/A	Chunk-level granularity
Encryption key operations	Logs all key generation, retrieval, escrow, recovery	N/A	Includes key owner and intent
Administrative actions	Logs all settings changes, role modifications, maintenance	N/A	Cannot be disabled
VM lifecycle	Logs creation, deletion, configuration changes, user authorization	N/A	Includes template and host details
Sharing and permissions	Logs group membership, permission grants, project access	N/A	Old and new values captured
Application-level alerts	Impossible travel, hash chain breaks, XSS, account locks	N/A	Real-time via configured drivers
Server health (CPU, memory, disk)	Not monitored	Nagios, Zabbix, Prometheus, PRTG, or equivalent	tiCrypt has no insight into hardware telemetry
Network monitoring (IDS/IPS, NetFlow)	Not monitored	Your network security stack	Complements tiCrypt's application-level view
OS-level events (syslog, auditd)	Not monitored	OS-native logging tools	Host-level events are outside tiCrypt's scope
Endpoint detection (EDR)	Not monitored	CrowdStrike, SentinelOne, or equivalent	Covers user workstations accessing tiCrypt
Physical access logs	Not monitored	Badge readers, camera systems	PE family controls
Vulnerability scanning	Not performed	Nessus, Qualys, OpenVAS, or equivalent	RA family controls
SIEM correlation across all sources	Provides data; does not correlate externally	Your SIEM platform	tiCrypt feeds in; the SIEM correlates

All data on tiCrypt infrastructure is encrypted at rest and in transit, so infrastructure telemetry (CPU utilization, disk I/O, network throughput) reveals nothing about the content of the data being processed. Infrastructure monitoring is for availability and performance, not data protection.

What tiCrypt covers

For AU practices specifically, tiCrypt provides:

• All operations within the enclave (authentication, file access, VM lifecycle, encryption key operations, administrative actions, group and project management, data uploads and downloads, sharing activities)
• Tamper-evident storage of all audit records with lifetime retention
• Real-time alerting for security-relevant events, including geolocation and impossible-travel detection
• SIEM integration via Splunk driver, console driver log file, REST API, and direct SQL
• Compliance reporting mapped to CMMC L2 AU practices
• Forensic investigation tooling (parameterized queries, object inspection, hash chain verification)

What your organization must provide

Each item below represents a gap your SSP must address. If a capability is not yet in place, it belongs on your Plan of Action and Milestones (POA&M) with a clear remediation timeline.

SOC integration and triage. tiCrypt delivers alerts to external systems. Your security operations center (SOC) must define escalation procedures, triage workflows, and response playbooks for tiCrypt alerts. The platform tells you something happened; the SOC determines what to do about it.

• SSP language: Document the specific alert routing from tiCrypt to your SOC, including which severity levels trigger which response actions.
• Potential POA&M item: If your SOC does not yet have tiCrypt-specific playbooks, document the gap and target completion date.

Infrastructure and host monitoring. tiCrypt audits application-level events. Server health monitoring (CPU, memory, disk utilization, service availability, network throughput) is the organization's responsibility. Use any standard infrastructure monitoring tool such as Nagios, Zabbix, Prometheus, or PRTG. tiCrypt has no insight into hardware telemetry. See the responsibility matrix above for details.

• SSP language: Identify the monitoring tools covering tiCrypt infrastructure and confirm they report into your centralized monitoring.
• Potential POA&M item: If tiCrypt hosts are not yet enrolled in your infrastructure monitoring, document the gap.

Network and endpoint monitoring. Network-level monitoring (IDS/IPS, NetFlow, DNS logging) and endpoint detection and response (EDR) for user workstations remain your responsibility. These are complementary: tiCrypt monitors the secure environment, while network and endpoint tools monitor the paths to and from it.

• SSP language: Describe how your network monitoring covers the tiCrypt network segment and how endpoint monitoring covers workstations that access tiCrypt.

Incident response procedures. NIST SP 800-171r2 practices 3.6.1 and 3.6.2 (CMMC L2 practices IR.L2-3.6.1 and IR.L2-3.6.2) require the organization to establish and maintain incident response capabilities and to track, document, and report incidents. tiCrypt provides the forensic evidence and audit trail. Your organization provides the response plan, the reporting chain, and the coordination with external parties (DoD, law enforcement, affected individuals).

• SSP language: Reference tiCrypt Audit as your forensic evidence source and describe the organizational incident response plan that consumes it.

Personnel security and training. NIST SP 800-171r2 practices in the PS and AT families (personnel screening, role-based training, insider threat awareness) are organizational controls that no technical platform can replace.

• Potential POA&M item: If CUI-handling personnel have not received training on tiCrypt-specific security procedures, document the gap.

Physical protection. The physical security of the data center hosting tiCrypt is the organization's responsibility. PE family controls require controlled physical access, visitor management, and environmental protections.

• SSP language: Document the physical security controls protecting the servers that host tiCrypt and tiCrypt Audit.

Risk assessment. RA family controls require the organization to conduct periodic risk assessments, scan for vulnerabilities, and remediate findings. tiCrypt reduces the technical attack surface but does not perform vulnerability scanning or risk assessment on the organization's behalf.

• Potential POA&M item: Ensure tiCrypt infrastructure is included in your vulnerability scanning scope.

SIEM correlation with non-tiCrypt sources. tiCrypt's audit data covers the enclave. If your organization operates other systems that handle CUI (email, collaboration tools, physical access logs), correlating events across all sources is a SIEM-level function that you manage.

• SSP language: Document all CUI-handling systems whose logs feed into your SIEM alongside tiCrypt audit data.

The practical boundary

tiCrypt handles 80 of the 110 NIST SP 800-171r2 practices through platform architecture and configuration. The deploying organization retains 26 practices that are inherently organizational (personnel, training, physical security, risk assessment, incident response, and maintenance) and 4 jointly managed practices. The audit system sits at the intersection: tiCrypt generates the evidence, and the organization operates the processes that consume it. Your SSP should document this shared responsibility model and show how the platform capabilities and organizational processes connect.

CMMC L2 / NIST SP 800-171r2 AU Control Mapping

The nine Audit and Accountability practices map directly to tiCrypt capabilities. The table below includes the CMMC L2 practice identifier, the NIST 800-171r2 practice number, and the specific evidence you can present to an assessor.

CMMC L2 Practice	NIST 800-171r2	Requirement	How tiCrypt Satisfies It	Assessment Evidence
AU.L2-3.3.1	3.3.1	Create and retain audit logs	150+ event types captured automatically; lifetime retention; no purging; logging cannot be disabled	Export pre-built compliance reports showing continuous logging across any requested time range
AU.L2-3.3.2	3.3.2	Trace actions to individual users	Every event is tied to an authenticated session with cryptographic identity, source IP, and timestamp	Run a per-user report demonstrating full traceability for any selected user
AU.L2-3.3.3	3.3.3	Review and update logged events	Pre-built queries, custom SQL, configurable alert rules; schema versioning supports evolving event definitions	Demonstrate the query interface; show how event definitions are updated across tiCrypt releases
AU.L2-3.3.4	3.3.4	Alert on audit processing failure	Alert drivers (Splunk, email, console) notify on hash chain breaks, logging failures, and anomalous conditions	Show the Hash Alert configuration and a sample alert delivered to your SIEM or email
AU.L2-3.3.5	3.3.5	Correlate audit review, analysis, and reporting	ClickHouse enables cross-event correlation by user, session, time, object, or any combination; REST API and console driver log file feed your SIEM for cross-system correlation	Show a SIEM dashboard that includes tiCrypt audit data correlated with other log sources
AU.L2-3.3.6	3.3.6	Provide audit reduction and report generation	Pre-built compliance reports; parameterized queries with filtering; Excel export; REST API for programmatic access	Generate a filtered report (e.g., all file access events for a specific project in a given month)
AU.L2-3.3.7	3.3.7	Synchronize system clocks	Millisecond-precision timestamps on all events; system time synchronized to NTP	Show NTP configuration and demonstrate consistent timestamps across tiCrypt components
AU.L2-3.3.8	3.3.8	Protect audit information from unauthorized access, modification, and deletion	SHA-256 hash chain provides tamper evidence; architectural separation from backend prevents write access from the production environment; role-based access to the audit interface	Run the hash chain verification to demonstrate integrity; show that backend compromise cannot alter audit records
AU.L2-3.3.9	3.3.9	Limit management of audit logging functionality	Only designated administrators can configure logging, manage alerts, or access the audit interface; logging itself cannot be disabled or reconfigured by any user	Show role-based access controls on the audit interface and demonstrate that logging configuration is restricted

Planning Your Deployment for CMMC L2 Assessment Readiness

For organizations deploying tiCrypt as part of CMMC Level 2 compliance preparation, the audit system requires minimal technical configuration but deliberate compliance planning.

Technical setup

1. SIEM integration: Determine which ingestion path fits your SOC workflow. Splunk environments should use the native HEC driver. All other SIEM platforms can consume the console driver's log file output, poll the REST API, or use an HEC-compatible endpoint if supported. See the ingestion matrix above.
2. Alert routing: Define which alert severities route to which teams. Critical alerts (hash chain breaks, XSS detection) should page on-call security. Info-level alerts (file downloads) may flow to a monitoring dashboard. If you want impossible-travel detection in IP alerts, configure a GeoIP2 database (MaxMind).
3. Network architecture: tiCrypt Audit communicates with the backend over port 25000 (inbound only). The audit web interface serves on port 443 behind Nginx. Plan firewall rules accordingly.
4. Independent deployment: Consider deploying tiCrypt Audit on a separate server from the backend for maximum tamper resistance. The architectural separation supports this configuration.

Compliance documentation

5. SSP integration: Include tiCrypt Audit in your System Security Plan as the mechanism satisfying all nine AU practices. Reference the control mapping table above and document the specific evidence artifacts you will present for each practice.
6. Shared responsibility documentation: Clearly document the boundary between platform-provided and organization-provided controls in your SSP. Use the responsibility matrix above as a starting point. Assessors will ask how you know where the platform's responsibility ends and yours begins.
7. POA&M review: Walk through the "What your organization must provide" section above to identify gaps. If your SOC playbooks, incident response procedures, infrastructure monitoring enrollment, or training programs are not yet updated for tiCrypt, document these as POA&M items with remediation dates that precede your assessment.
8. Evidence dry run: Before your assessment, generate the reports and run the queries you plan to show the assessor. Confirm that your SIEM integration is active and that tiCrypt alerts appear in your SOC dashboards. Assessors evaluate not just capability but operational use.

tiCrypt begins generating tamper-evident audit records at deployment. Logging is always on, hash chaining is always active, and retention is indefinite. The platform addresses the nine AU practices and produces the evidence artifacts relevant to assessment. SOC triage, infrastructure monitoring, incident response procedures, personnel controls, and physical security remain organizational responsibilities that must be documented in your SSP and addressed before assessment. The responsibility matrix and control mapping in this article are intended as a starting point for that documentation.