Most vulnerability tools are built for the people who find and fix the problems. Compliance and audit officers live one layer above that work. Your job is not to triage the next critical finding. Your job is to prove, on demand, that the program ran the way the policy said it would. You need to show who did what, when they did it, whether deadlines were met, and what happened when they were not. That proof has to hold up when an external assessor pulls a sample and asks you to walk through it line by line.
The hard part is that evidence is usually an afterthought. Teams chase remediation all year, then scramble to reconstruct the story before an audit window. Spreadsheets get backfilled. Email threads get screenshotted. Timestamps drift because nobody recorded them at the moment of action. By the time the assessor arrives, the evidence is a narrative assembled in hindsight rather than a record captured at the source.
PMAP treats evidence as a first-class output of normal operations, not a special export you run before an audit. Two independent audit trails capture security events and entity activity as they happen. Service-level agreements behave as enforced controls with documented escalation, not as dashboard numbers. This article walks through what an audit officer actually has to produce and how PMAP generates that material across the Ingest, Correlate, Triage, and Remediate lifecycle. For the broader regulatory framing, see the pillar guide on vulnerability management compliance and audit.
What an Audit Officer Has to Prove
An auditor rarely asks whether your program is good in the abstract. They ask for specific, checkable assertions. Can you show that access to a sensitive system was granted to a named person on a known date and revoked when it expired. Can you show that a critical finding was assigned, worked, and closed inside its committed window. Can you show that when a deadline slipped, the right people were notified according to a documented escalation path. Each of these is an evidence request, and each one fails if the underlying record was never captured at the moment it mattered.
This is the core difference between a metric and an evidence trail. A metric tells you the average days to close was within target. An evidence trail lets you select one finding, point to the exact event that opened it, the event that assigned it, the event that resolved it, and the deadline it was measured against. Frameworks such as the AICPA SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 are sampled, not summarized. The assessor picks records at random and expects every one to stand on its own.
PMAP is built around the same security event ledger that the audit officer needs to defend the program. The platform records compliance-critical actions synchronously, preserves evidence even after the underlying record is deleted, and treats SLA deadlines as controls with a defined escalation chain. The rest of this article shows each mechanism and the audit question it answers.
Two Audit Trails, Two Jobs
PMAP keeps two separate audit trails because compliance evidence and operational activity have genuinely different requirements. Treating them as one log would force a compromise on both.
The first is the security audit trail, stored in the access_audit_events table. This is the compliance-grade ledger. It captures a deliberately narrow set of high-consequence events: login success and failure, access grant, access revoke, access expiry, the full role lifecycle, sensitive views, and destructive deletes of findings, projects, and assets. Because these events are the ones an assessor samples, they are written synchronously to the database on the request path. The action and its audit record commit together, so event ordering is preserved exactly as it occurred. There is no background queue that could reorder or delay a security event.
The second is the activity audit trail, stored in the activity_logs table. This is the high-throughput operational log. It records every entity-level action across the platform: finding creates and updates, bulk imports, asset mutations, scan events, SLA breaches, and more. The volume here is far higher than the security trail, so it uses a batched, fire-and-forget writer that drains an in-memory channel in efficient database round-trips. This keeps the operational hot path fast while still recording everything.
For an audit officer this separation matters in practice. When an assessor asks “show me everyone who was granted access to this tenant,” you query the security trail, which is small, ordered, and purpose-built for that question. When you need to reconstruct the full life of a single finding, you draw on the activity trail, which carries the dense operational history. You are not filtering thousands of routine CRUD rows to find the handful of access events that the auditor cares about. This dual-trail design is covered in more depth in the dual audit trails cluster article.
Typed Events and Tamper-Resistant Ordering
The security trail does not accept arbitrary event strings. It recognizes twelve named event-type constants: login_success, login_failed, access_granted, access_revoked, access_expired, role_created, role_updated, role_deleted, sensitive_view, finding_deleted, project_deleted, and asset_deleted. This closed vocabulary is enforced in two places at once. The application defines the constants so a typo cannot compile, and the database enforces a CHECK constraint so a malformed value cannot be written even if something bypassed the application layer.
The audit value of this design is consistency. An assessor reviewing access events sees the same vocabulary every time, with no near-duplicate strings like access-granted versus access_granted to reconcile. Adding a new event type is a deliberate change that requires both a code constant and a paired database migration to extend the constraint. Nothing slips into the security ledger informally.
Synchronous writes give you ordering you can defend. Because each security event is inserted directly on the request path rather than handed to a background scheduler, the recorded sequence reflects the real sequence of actions. When you walk an assessor through an access grant followed by a later revoke, the timestamps and order are the ones captured at the moment each action happened. This aligns with the audit and accountability expectations in the NIST SP 800-53 AU control family, which centers on complete, time-ordered, attributable records.
Completeness Over Latency: Why No Event Is Dropped
The most damaging gap in any audit trail is a missing event. An assessor who finds one unexplained hole begins to doubt the whole record. PMAP is designed so that audit completeness always wins over speed.
The activity trail uses a batched background writer for throughput, but it never trades away completeness to get it. When the in-memory buffer is full, the writer does not discard the event and it does not silently drop the row. It falls back to a synchronous single-row write on the caller’s own path, and it warns operators so they can tune the queue. The event is recorded either way. Under load the system gets slower rather than lossy, which is exactly the trade an auditor wants.
Shutdown is handled with the same priority. When the platform stops, the audit queue drains every pending event before the process exits. The drain runs after the HTTP listener has closed and all in-flight requests have finished, so every action that completed during a request is flushed to the database first. A routine restart or a planned deployment does not leave a gap in the record.
The security trail carries an additional guarantee around failure isolation. If a security audit write encounters a database error, the error is logged but never propagated back to the calling handler. The audit layer is built so it cannot become a second failure mode for the operation it records. An attempt to log an access change can never break the access change itself. For the audit officer, this means the trail is engineered to capture events through buffer pressure, shutdown, and write errors alike. The default posture is that the event gets recorded.
Evidence That Survives a Deletion
Deletion is where naive audit logs fail an assessment. A team deletes a finding, a project closes out, an asset is decommissioned, and six months later the auditor asks what that record was. If the audit log only stored a foreign key to the now-deleted row, the answer is a dead reference and an empty cell. The event happened, but the evidence of what it touched is gone.
PMAP handles this with an entity-name fallback baked into the deletion events. When a finding_deleted, project_deleted, or asset_deleted event is written, the human-readable name of that entity is captured into the event payload at the moment of deletion. Later, when the joined entity row no longer exists, the audit view falls back to the name stored in the payload. The record still tells you what was deleted, by whom, and when, long after the underlying object is gone.
This is precisely the case that breaks reconstructed-after-the-fact evidence. You cannot screenshot a record you already deleted. By capturing the name at emit time, PMAP keeps destructive actions accountable across the full retention period. An auditor sampling deletion events sees meaningful entries rather than orphaned identifiers, which is what a complete audit and accountability control is supposed to deliver.
SLA as a Compliance Control, Not Just a Metric
For an audit officer, a service-level agreement is not a performance dashboard. It is a control. A control has a defined threshold, a defined owner, and a defined response when it is breached. PMAP models SLA exactly this way, which is what lets an SLA policy serve as audit evidence rather than just a reporting number.
SLA thresholds in PMAP are a severity-to-hours mapping that governs how long a finding of a given severity may stay open before it breaches. Those thresholds can be set at two scopes. A company-level config applies to every finding within a company. A project-level config applies within a specific project and overrides the company level. This lets you encode different contractual or regulatory commitments where they actually apply. A regulated subsidiary or a customer engagement with a tighter remediation clause gets its own threshold without changing the rest of the program.
The resolution follows a documented precedence chain, which is what makes the control auditable rather than ambiguous. For any finding, PMAP resolves the deadline by walking the layers in order: project config first, then company config, then the platform global defaults from admin settings, then built-in hardcoded values, and finally a 7-day backstop. A level is skipped only when its config row is absent or that specific severity is left unset. The first defined value wins. When an assessor asks why a particular finding had a 72-hour deadline, you can point to the exact layer that supplied it. There is no guesswork about which policy governed which finding.
The hardcoded fallback values are themselves part of the control story. If nothing else is configured, urgent findings get 24 hours, critical 72 hours, high 168 hours (7 days), medium 720 hours (30 days), and low 2160 hours (90 days). The program is never operating without a defined deadline. Every finding is measured against something, which means there is always a threshold to audit against. This maps cleanly onto the deadline-driven expectations of PCI DSS v4.0 and the timeliness emphasis in NIST vulnerability management guidance. The SLA deadline calculation logic is detailed further in the SLA deadline calculation cluster article.
Deadline Recalculation as Severity Changes
A control is only credible if it stays accurate when conditions change. A finding does not always keep its original severity. Triage may reclassify a medium as a critical, or a reassessment may downgrade it. If the deadline stayed frozen at the original severity, the SLA control would be measuring against a stale commitment and your evidence would not match policy.
PMAP recalculates the deadline whenever the inputs change. When an SLA config is saved at the company or project scope, the platform immediately recomputes the deadline for every open finding in that scope and reports how many were affected. The recalculation also runs when a finding’s severity is updated, when a paused SLA clock resumes, and during bulk status changes. The formula is consistent and traceable. The new deadline is the finding’s creation time plus the resolved hours for its current severity plus any accumulated pause hours. That last term matters for fairness. If a finding was legitimately paused, the time it spent paused is not counted against the remediation window, and the math shows exactly how the adjustment was made.
There is also a reset-notified flag that keeps the escalation pipeline honest. During bulk recalculation, if the new deadline lands in the future, the finding’s notified flag is reset so the notification layer fires again as the extended deadline approaches. A finding that was previously marked as notified does not silently fall off the radar after its deadline is recomputed. The control keeps watching.
Three-Level Escalation as Documented Routing
A breached deadline is not the end of the control. It is the start of the response, and the response is where many programs lose their evidence. “We told someone” is not an audit answer. “The policy routed this breach to a named first contact two days after breach, then to a second contact, then to a third, and here is the configuration that defined that path” is an audit answer.
PMAP lets each SLA config specify up to three escalation contacts. Each level pairs a user with a days-after-breach trigger, so you can encode a tiered chain. A breach might route to the asset owner immediately, to a team lead a few days later, and to a manager after that. Because escalation is configured at company or project granularity, the routing matches the same scope boundaries as the thresholds. A regulated unit can have a stricter escalation chain than the rest of the organization, and that difference is part of the documented configuration rather than an informal arrangement.
For an audit officer this turns escalation into something you can present rather than describe. The chain exists in configuration. The trigger timing is explicit. When an assessor asks what happens when a critical finding breaches its deadline, you show the actual escalation levels and their day offsets, then point to the breach and escalation events recorded in the activity trail. The intent and the execution line up. This escalation model is explored further in the SLA escalation policy cluster article.
Who Had Access and When
Access governance is one of the most heavily sampled areas in any audit. SOC 2 and ISO 27001 both push hard on the question of who could touch sensitive systems and whether that access was granted, reviewed, and removed appropriately. PMAP records the full access lifecycle in the security trail as discrete, typed events.
Every access grant writes an access_granted event. Every revocation writes an access_revoked event. When a time-bound grant reaches its expiry, a background job announces it and writes an access_expired event, so even access that lapses automatically leaves a record. You are not relying on someone to remember to log the removal. The expiry is captured as its own event with its own timestamp. The role lifecycle is recorded the same way through role_created, role_updated, and role_deleted events, so changes to the permission structure itself are auditable, not just individual grants.
This directly answers the access-review questions an assessor asks. To show who held access to a tenant and when it ended, you read the security trail filtered to that scope and event types. The grant, any revoke, and the expiry are all there in order. This kind of complete, attributable access record is what the access-control objectives in SOC 2 and the access-management controls in ISO/IEC 27001:2022 are written to verify.
Reading the Audit Log Without Raw UUIDs
An audit trail full of opaque identifiers is technically complete and practically useless. If every actor and target is a bare UUID, an assessor cannot read the record without a side lookup for every line, and an audit officer cannot present it with confidence. PMAP resolves names server-side so the audit log is legible at the point of reading.
The security audit query joins and resolves the human-readable values as it returns rows: the actor’s name and email, the target user’s name, the target role’s name, the scope name, and the target entity’s name. The scope name in particular is resolved by branching on the scope type, so a company scope resolves against companies and a project scope resolves against projects. The result is an audit view where each row reads as a sentence about who did what to which target in which scope, rather than a grid of identifiers.
This is more than a convenience. Resolving names at read time means the evidence you hand an assessor is self-describing. A sampled row stands on its own without a separate identity-mapping spreadsheet. Combined with the deletion-name fallback described earlier, even events touching records that no longer exist remain readable. The audit log is something you can put in front of an auditor directly. The security audit read endpoint is restricted to platform administrators, which keeps the compliance ledger itself access-controlled.
Mapping PMAP Evidence to SOC 2 and ISO 27001
It helps to connect these mechanisms back to the frameworks an audit officer answers to. The mapping is not marketing. It is a direct line from a specific PMAP behavior to a specific control objective.
For access control, the security trail’s access_granted, access_revoked, and access_expired events provide the attributable, time-ordered record that the SOC 2 logical access criteria and the ISO/IEC 27001:2022 access-control objectives expect. You can demonstrate that access was provisioned to named identities and removed on schedule.
For change accountability, the role lifecycle events and the entity deletion events with name fallback support the audit and accountability requirements echoed across the NIST SP 800-53 AU control family. Destructive and structural changes are recorded with enough context to remain meaningful over the retention period.
For timeliness of remediation, the SLA control with its precedence chain, recalculation, and three-level escalation provides documented evidence that findings were governed by defined deadlines and that breaches triggered a defined response. This is the kind of remediation discipline that PCI DSS v4.0 and the broader NIST vulnerability management guidance look for.
For completeness, the synchronous fallback, graceful drain, and failure isolation collectively support the assertion that the audit record is complete. You can speak to why no event is silently dropped, which is often the first thing a rigorous assessor probes.
None of this requires a separate compliance module bolted onto the platform. The evidence is a byproduct of the platform doing its normal work across Ingest, Correlate, Triage, and Remediate. That is the point. Evidence captured at the source is stronger than evidence assembled before an audit.
How PMAP Keeps You Audit-Ready Every Day
The shift PMAP offers an audit officer is from periodic reconstruction to continuous capture. You are not building the evidence package in the weeks before an assessment. The evidence accumulates as the program runs, because the security events, the activity history, the SLA deadlines, and the escalation routing are all recorded at the moment they occur.
That changes the rhythm of audit work. Instead of a fire drill, an audit becomes a query. When the assessor samples a finding, you pull its full activity history. When they sample an access change, you pull the typed security event with names already resolved. When they question a deadline, you point to the precedence layer that set it and the escalation chain that governed its breach. The answers exist before the question is asked.
It also changes the conversation with the teams you support. Because the SLA is an enforced control with recalculation and escalation rather than a passive metric, remediation behavior and audit evidence are produced by the same mechanism. The work people do to close findings on time is the same work that proves they did. Compliance stops being a tax on the security team and becomes a record the security team generates simply by operating.
If your next audit is on the calendar, the most useful thing you can do now is make sure the evidence is being captured at the source rather than reconstructed at the deadline. Download the audit trail datasheet and walk into your next audit with evidence ready. For the wider compliance context that surrounds this role, start with the pillar on vulnerability management compliance and audit, then dig into the dual audit trails and SLA escalation policy articles for the underlying mechanics.
