There is a moment in almost every security program when the work changes character. For a long time the goal is simply to find vulnerabilities and fix them. Then an auditor arrives, or a customer sends a security questionnaire, or a regulator asks for proof, and suddenly the question is no longer whether the work happened. The question is whether you can prove it happened. Proving it is a different discipline from doing it. A team can remediate every critical finding inside its deadline and still fail an audit because it cannot reconstruct who closed what, when, on whose authority, and against which agreed timeline.
This guide is about that proof. It treats compliance not as a separate project bolted onto vulnerability management but as a property that a well-instrumented program produces as a byproduct of normal operation. The strongest evidence is the kind nobody had to remember to create. It is generated automatically as findings move, approvals are granted, deadlines are set, and access changes hands. Every claim in this article is grounded in how PMAP actually records those events, because evidence is only worth presenting if it is reproducible and tamper-resistant. A compliance story built on screenshots and exported spreadsheets falls apart under the first sharp question.
You can read this top to bottom as a reference for designing the evidentiary layer of your own program, or jump to the section that matches the control you are being asked about right now. Audit evidence here is the quiet companion to the rest of the vulnerability management lifecycle. Findings are ingested, correlated, triaged, and remediated, and alongside that motion a parallel record accumulates that lets you defend every decision after the fact. The angle of this article is deliberately narrow. It is about compliance, evidence, and escalation. The metric and reporting angle on SLA lives in the vulnerability risk analytics guide, and the two are designed to complement rather than repeat each other.
What Auditors Actually Ask of a VM Program
Auditors are rarely impressed by the size of a vulnerability backlog or the sophistication of a scanner stack. They ask narrower, more awkward questions. Can you show that a documented process exists. Can you show that the process was actually followed, not just written down. Can you produce, for a specific finding chosen at random, the full chain of custody from the moment it appeared to the moment it was closed. Can you demonstrate that sensitive actions required a second person. Can you prove that access to the system itself was controlled and that grants were reviewed and revoked on time.
Behind all of these questions sits a single requirement that runs through frameworks like ISO/IEC 27001:2022, the AICPA SOC 2 Trust Services Criteria, and the AU audit and accountability family of NIST SP 800-53. That requirement is accountability. Every consequential action should be attributable to an identity, fixed in time, and recorded somewhere that the actor cannot quietly alter. A program that cannot meet that bar is not insecure by definition, but it is undefendable, and in an audit undefendable and failing look identical.
PMAP treats this accountability requirement as cross-cutting infrastructure rather than a feature that lives in one screen. Its audit domain is described in the product wiki as a compliance-grade security event ledger, and the word ledger is chosen deliberately. A ledger is not a report you generate on demand from data that might have changed. It is an append-only record written as events occur. The rest of this article walks through how that ledger is built, how SLA timelines turn into a control auditors can test, how four-eyes approval enforces separation of duties, and how all of it maps back to the frameworks an auditor carries in.
Dual Audit Trails: Security Events and Activity Logs
The first design decision worth understanding is that PMAP does not keep one audit trail. It keeps two, and they exist because two genuinely different kinds of evidence have two genuinely different requirements. Collapsing them into a single log would force one set of trade-offs onto both, and the result would be worse evidence for both.
The first trail is the security audit. It records high-consequence security actions: login success and failure, access grant, revoke and expiry, the full lifecycle of role definitions, sensitive views, and destructive deletes. These events are comparatively rare, and every one of them matters individually. An auditor reviewing access control wants to see each grant and each revocation, in order, with no gap. This trail is written synchronously and directly to the database on the request path. Because the write happens inline rather than being handed to a background worker, the order in which events were recorded reflects the order in which they actually occurred. There is no risk that two access changes land in the log out of sequence because of scheduling, which is exactly the property you want when the question is who had access first.
The second trail is the activity audit. It records every entity-level action across the platform: finding creation and update, bulk import, asset mutation, scan events, SLA breaches, and far more. This is a high-volume stream. A single bulk import or a busy scan wave can generate thousands of entries in a short window, and writing each one synchronously on the request path would slow the very operations being recorded. So this trail is batched. A background worker drains an in-memory channel and writes events in efficient batches to reduce pressure on the database. The two trails together give an auditor both the precise, ordered record of security-critical actions and the broad, high-volume record of everything the program did.
This separation is not an accident of implementation. It reflects a principle stated plainly in the product wiki. Auditing must not add a second failure mode to the operations it records. The system that writes the evidence is built to be quieter and more reliable than the systems it observes, because an audit trail that can break the thing it is watching is worse than no audit trail at all.
Typed Event Kinds and Tamper-Evident Ordering
Within the security audit trail, events are not free-form strings. They are typed. PMAP defines a fixed set of named event-type constants covering login success and failure, access granted, revoked and expired, role created, updated and deleted, sensitive view, and the three destructive deletes for findings, projects, and assets. The value of typing is twofold. First, it makes the log queryable in a precise way. An auditor asking to see every access revocation in a quarter gets a clean filtered result rather than a fuzzy text search across a comment field. Second, the allowed values are enforced at the database layer through a CHECK constraint, not only in the application code. A new event type cannot be recorded unless a paired database migration has extended the constraint to permit it. Mismatched values fail at the database and are never silently written, which means the vocabulary of the audit log is governed and stable over time rather than drifting as developers add ad-hoc strings.
The synchronous, inline write is what gives this trail its tamper-evident ordering property. Because security events are inserted directly as the action occurs rather than queued for later, their recorded sequence is the true sequence of events. Combined with actor enrichment, which automatically captures the acting user, the client IP, and the user agent from the request, each entry carries enough context to stand on its own. The IP itself is normalized, with the port stripped and the first forwarded hop trusted from the upstream proxy, so the address recorded is the address that matters rather than an internal load-balancer artifact. An auditor reading this trail sees a coherent, attributable, ordered story rather than a pile of disconnected log lines.
SLA as a Compliance Control
Most teams think of a service-level agreement as an operational target. Close criticals in so many hours, highs in so many days, and so on. That framing is correct but incomplete. From a compliance standpoint, an SLA is a control. It is a commitment the program has made, usually to a customer, a regulator, or an internal risk policy, and an auditor will test whether the commitment was kept. The difference between an operational target and a control is that a control has to be configurable, enforced consistently, and provable after the fact. PMAP's SLA configuration is built with all three properties in mind.
An SLA configuration in PMAP is a mapping from severity to a number of hours. A finding of a given severity may remain open only so long before it breaches. What makes this a usable compliance control rather than a single global setting is that it can be defined at two scopes. A company-level configuration sets thresholds for every finding within a tenant, and a project-level configuration sets thresholds for a specific engagement, overriding the company level. This matters because real contractual obligations are not uniform. A managed customer with a tight remediation clause in their contract needs tighter deadlines than the internal default, and the platform lets you encode that obligation precisely where it applies. The thresholds also support partial overrides. Any individual severity can be left to inherit from the level above, so an administrator can tighten only the deadline that the contract actually constrains and let the rest cascade from the broader policy.
When a configuration is saved, the platform does not wait for a nightly job to apply it. Saving a company or project configuration immediately triggers a recalculation of the SLA deadline for every open finding in scope, and the number of findings affected is returned to the caller so the change is confirmed rather than assumed. There is also an explicit on-demand recalculation that lets an administrator re-run the deadline computation without changing the configuration, which is exactly what you want after a global default changes and you need every existing finding to reflect the new policy. For an auditor, this behavior is reassuring. It means the deadlines visible on findings are not stale relics of an old policy. They are the live consequence of the current, configured commitment, recomputed deterministically from each finding's creation time plus its resolved threshold plus any accumulated pause hours. The angle here is evidentiary rather than statistical. For breach rates, MTTR, and the trend view that turns these timelines into management metrics, the vulnerability risk analytics guide carries that load.
Three-Level Escalation Routing
A deadline on its own is a passive thing. It marks a moment in the future, but if nothing happens as that moment approaches, the deadline simply slides past and the breach is discovered later, often during the audit you were trying to pass. Compliance regimes increasingly expect not just that you set deadlines but that you have a defined response when those deadlines are at risk. This is where escalation routing turns an SLA from a number into an enforced process.
Each SLA configuration in PMAP can specify up to three escalation contacts, and each contact is paired with a number of days after breach that triggers that level. The result is a tiered escalation chain configurable at company or project granularity. The first level might notify the assigned remediation owner, the second their manager, and the third a security leader or compliance officer, each engaged at a defined interval. The point of three distinct levels is that it encodes a real organizational response rather than a single ping into a void. An auditor reviewing how the program handles aging findings can see not only that deadlines exist but that the program has defined, in configuration, exactly who gets pulled in and when as a finding approaches and then crosses its line.
On the finding side, this is not merely a notification fired and forgotten. Findings carry escalation acknowledgement and an escalation history, so the record shows that an escalation was raised, that it was acknowledged, and by whom. That history is itself evidence. When an SLA does breach, and in any real program some eventually will, the defensible position is not pretending it never happens. It is showing that the breach was detected, routed up the chain as configured, acknowledged by the right people, and worked rather than ignored. A program that can produce that trail for a breached finding is in a far stronger audit position than one that simply reports a lower breach count it cannot substantiate.
Four-Eyes Approval for Sensitive Changes
Separation of duties is one of the oldest controls in security and one of the most consistently demanded by auditors. The principle is simple. Certain actions are consequential enough that a single individual should not be able to perform them alone. A second authorized person must review and approve. In the vulnerability management context, the most common application is the decision to make a finding effectively go away without fixing it. Marking something a false positive, accepting the risk, or otherwise removing it from the active backlog is exactly the kind of action that, if left to a single hand, invites both honest error and the occasional convenient shortcut under deadline pressure.
PMAP supports this through approvals on sensitive status changes. A status transition that requires sign-off passes through an approval gate rather than taking effect immediately, and the request enters an explicit approval workflow. The set of people who can approve is not hardcoded. It is resolved through the authorization layer, which unions the built-in administrative roles with any custom role that has been granted the finding approve permission in the relevant company. This means the right to approve is itself a governed grant, visible in access management and subject to the same scoping as every other permission. An organization can decide precisely which roles may sign off on accepting risk, and that decision is enforced consistently rather than depending on who happens to have the access.
The reason this matters so much for compliance is that four-eyes approval produces evidence at exactly the point of highest risk. The moment a finding is removed from active tracking is the moment an auditor is most interested in, because it is where a program could quietly lower its own numbers. An approval record showing that the change was requested by one identity and approved by a different authorized identity is direct, durable proof that separation of duties was enforced for that decision. For a deeper treatment of the principle itself and how it compares to single-approver workflows, the four-eyes approval cluster article goes further, but the evidentiary point stands on its own. Sensitive changes carry a second signature, and the signature is recorded.
Deletion Evidence That Survives the Delete
There is a subtle and genuinely hard problem at the heart of audit logging, and the way a system handles it tells you how seriously it takes evidence. The problem is this. When something is deleted, the most natural way to display its audit entry later is to join back to the original record and show its name. But the record is gone. That is the whole point of a deletion. A naive audit log ends up showing an entry that says a finding was deleted but can no longer say which finding, because the row it would have named no longer exists. The evidence of the most consequential action, destruction, is exactly the evidence most likely to be hollow.
PMAP solves this by capturing the context at the moment of emission rather than relying on a later join. The destructive delete events for findings, projects, and assets are among the typed security events, and when one is recorded the payload captures the entity name at the time of deletion. So even though the joined row is gone, the audit interface can fall back to the name stored in the event itself. The record of what was destroyed survives the destruction. The asset domain, for instance, emits a security audit event on deletion specifically so that the evidence outlives the asset.
This is the kind of detail that does not show up in a feature comparison but decides whether an audit goes smoothly. An auditor asking what happened to a finding that is no longer in the system needs an answer, and undefendable is the same word that applies when the only honest answer is that the record was deleted along with everything about it. By preserving the name and the actor and the timestamp in an append-only security event, PMAP keeps the chain of custody intact through the one operation that most threatens it. The deletion is logged as a deliberate, attributed act rather than a silent disappearance.
Compliance-Aligned Reporting
Evidence that lives only in a query interface is useful to the person running the query, but an audit usually needs a document. Something that can be handed over, attached to a report, retained in a file, and referred back to. PMAP's reporting layer is where the accumulated record becomes a deliverable, and several of its properties are aimed squarely at the compliance use case.
The platform produces a company risk posture report that summarizes the state of a tenant's program, and reports can be signed. Report signing matters because a signed document carries an assertion of integrity. It says this is the report as it was produced, by this party, and it has not been altered since. For an evidence package that may be reviewed months later by a third party, that integrity property is the difference between a credible artifact and an editable file that proves nothing. Reports can also be shared securely through controlled access rather than circulated as loose attachments, which keeps the distribution of sensitive posture information itself within the program's control.
Underneath the reports sits the named audit log query, which lets an authorized administrator retrieve security audit events with the actor, target, role, scope, and entity names already resolved on the server side. The interface never asks a reviewer to interpret raw identifiers. It shows the human-readable who, what, and where. This is more important than it sounds. An audit trail that displays opaque identifiers forces the auditor to trust a translation they cannot see, whereas one that resolves names server-side, consistently, lets the evidence speak for itself. Together the signed posture report and the resolved audit log give a program two complementary forms of compliance output. One is the summary an executive or auditor reads, and the other is the granular record they drill into when the summary raises a question.
Mapping PMAP Evidence to SOC 2 and ISO 27001
It helps to connect the mechanisms above to the frameworks an auditor actually works from, without overclaiming. No software makes an organization compliant on its own. Compliance is an organizational state that depends on policy, people, and process as much as tooling. What a platform can do is produce the evidence that the relevant controls are operating, and it is worth being precise about which controls each mechanism supports.
For SOC 2, the Trust Services Criteria lean heavily on logical access, change management, and monitoring. The security audit trail, with its typed access events and ordered, attributed records of grants, revocations, and expiries, speaks directly to the logical access criteria. The four-eyes approval workflow supports the change management and separation-of-duties expectations by proving that sensitive changes required a second authorized party. The activity log and the SLA control together support the monitoring expectation by showing that the program tracks its own work and responds to aging items on a defined schedule.
For ISO/IEC 27001:2022, the Annex A controls around access control, logging and monitoring, and management of technical vulnerabilities are the natural anchors. The dual audit trails provide the logging and monitoring evidence. The scoped, time-bound nature of access grants, audited at every grant and revoke, supports the access control objectives. The SLA configuration and escalation routing provide evidence for the technical vulnerability management expectation that vulnerabilities are not merely identified but remediated against defined timelines with a defined response when those timelines slip. The AU family of NIST SP 800-53 maps cleanly onto the audit trail design, since its content, retention-friendliness, and protection-from-tampering goals are precisely what the synchronous, typed, constraint-governed security log is built to satisfy. The honest framing throughout is that PMAP supplies the evidentiary substrate. The auditor still tests, and the organization still owns the policy, but the substrate is there to be tested rather than reconstructed in a panic.
Vendor Qualification as Compliance Input
One area that programs often overlook in their compliance posture is the assurance story around the third parties who do security work on their behalf. When an external pentest firm or consultancy performs assessments, an auditor may reasonably ask how the program knows that firm is qualified, and whether that qualification is tracked rather than assumed. This is supply-chain assurance applied to the security function itself.
PMAP carries qualification tracking for consulting firms, which turns vendor competence from an informal belief into a recorded attribute of the program. A firm's qualification status becomes part of the same governed environment as everything else, which means that when assessment findings flow in from an external party, there is a recorded basis for trusting the source. For a compliance reviewer examining how the organization manages its assessment supply chain, this closes a gap that is easy to miss. It connects the people doing the work to the evidence the work produces, so that the chain of custody on a finding extends all the way back to a qualified, recorded source rather than terminating at an anonymous import. The depth of the identity and access side of this story, including how roles and scoped grants govern who can do what across tenants, is carried by the multi-tenant access cluster, but the qualification signal itself belongs in the compliance picture because it is part of how the program defends the trustworthiness of its inputs.
How PMAP Produces Audit-Ready Evidence
It is worth stepping back to see how these mechanisms fit together, because their real power is in the combination rather than any single piece. The defining characteristic of PMAP's approach to compliance is that evidence is a byproduct of normal operation rather than a separate exercise. Nobody has to remember to write down that a finding was approved, that an access grant expired, or that an asset was deleted. Those records are produced automatically, at the moment the action happens, by infrastructure designed to be more reliable than the systems it watches.
Walk a single finding through its life and the evidentiary layer reveals itself. The finding is created, and an activity record captures the creation. Its SLA deadline is resolved from the configured threshold for its severity at its scope, recomputed deterministically rather than guessed. As it ages toward that deadline, the escalation chain engages at the configured levels, and the acknowledgement is recorded. If someone moves to accept its risk, the change passes through four-eyes approval and a second signature is captured. If it is instead remediated and later deleted, the deletion is logged as a typed security event that preserves its name. Every one of those steps was attributable to an identity, fixed in time, and written to a trail the actor cannot quietly rewrite. That is precisely what an auditor means by accountability, and it is produced without a single person doing anything other than their normal job.
This is the quiet half of vulnerability management. The visible half is finding and fixing. The evidentiary half is being able to prove, later, exactly what was found, what was decided, on whose authority, and against which commitment. A program that does both does not merely reduce risk. It can demonstrate that it reduces risk, on demand, to a skeptical third party, which is increasingly what the business, the customer, and the regulator actually require. When you are ready to put this layer in place, the audit trail and compliance evidence datasheet maps the mechanisms to the controls, and the governing risk with RBAC, approvals and audit ebook walks through how access, sign-off, and the audit ledger reinforce each other across a whole program.
Frequently Asked Questions
What is the difference between PMAP's two audit trails?
PMAP keeps a security audit trail and an activity audit trail because they serve different evidentiary needs. The security audit is a synchronous, typed, ordered record of high-consequence actions such as login, access grant and revoke, role lifecycle, and destructive deletes. It is written inline so its sequence reflects the true order of events. The activity audit is a high-volume, batched record of every entity-level action across the platform, written through a background worker so it does not slow the operations it records. An auditor uses the first for precise access and deletion evidence and the second for the broad record of everything the program did.
Does PMAP make my organization SOC 2 or ISO 27001 compliant?
No platform makes an organization compliant on its own, and it is worth being clear about that. Compliance is an organizational state that depends on policy, people, and process. What PMAP does is produce the evidence that relevant controls are operating, in a form an auditor can test. The typed security audit trail supports logical access and audit-and-accountability controls, four-eyes approval supports separation of duties, and the SLA configuration with escalation routing supports the technical vulnerability management expectation. The organization still owns the policy and the auditor still performs the assessment, but the evidentiary substrate is there to be examined rather than reconstructed.
How does PMAP turn an SLA into something an auditor can verify?
An SLA in PMAP is a configured mapping from severity to hours, set at company or project scope so it can match real contractual obligations rather than a single global default. When the configuration is saved, the platform immediately recomputes the deadline for every open finding in scope, so the deadlines shown are the live consequence of the current policy rather than stale values. Each deadline is derived deterministically from the finding's creation time, its resolved threshold, and any accumulated pause hours. Because the computation is repeatable and the thresholds are explicit, an auditor can independently confirm that a given finding's deadline matches the committed policy.
What is four-eyes approval and why does it matter for compliance?
Four-eyes approval is the enforcement of separation of duties on consequential actions. In PMAP, sensitive finding status changes, such as accepting risk or marking a false positive, can require a second authorized person to approve before the change takes effect. The set of approvers is resolved through the authorization layer, unioning administrative roles with custom roles granted the finding approve permission, so the right to approve is itself a governed grant. This matters for compliance because the moment a finding leaves active tracking is exactly where a program could quietly lower its own numbers. An approval record with two distinct identities is direct proof that separation of duties was enforced at that point.
How does PMAP keep evidence of something that was deleted?
Deletion is the hardest case for an audit log because the record you would normally name no longer exists. PMAP handles this by capturing context at the moment of emission rather than relying on a later join. The destructive delete events for findings, projects, and assets are typed security events, and when one is recorded the payload stores the entity name at the time of deletion. So the audit interface can show what was deleted, by whom, and when, even though the original row is gone. The chain of custody survives the one operation that most threatens it, and the deletion appears as a deliberate, attributed act rather than a silent disappearance.
Can PMAP produce a compliance document I can hand to an auditor?
Yes. The reporting layer produces a company risk posture report, and reports can be signed so the document carries an assertion of integrity, meaning it is the report as produced and has not been altered since. Reports can also be shared through controlled access rather than circulated as loose attachments. Beneath the reports, the named audit log query retrieves security events with actor, target, role, scope, and entity names already resolved server-side, so a reviewer reads a human-readable record rather than raw identifiers. Together the signed posture report and the resolved audit log give you both the summary an auditor reads and the granular record they drill into.
Where do escalation contacts fit into audit evidence?
Each SLA configuration can specify up to three escalation contacts, each paired with a number of days after breach that triggers that level, configurable at company or project granularity. This encodes a defined organizational response to aging findings rather than a single notification. On the finding itself, escalation acknowledgement and history are recorded, so the trail shows that an escalation was raised, acknowledged, and by whom. When a deadline does breach, the defensible position is not a lower breach count you cannot substantiate. It is a record showing the breach was detected, routed up the configured chain, acknowledged by the right people, and worked.
