The audit question, answered before it is asked
Which control does this finding affect, and what did you do about it?
Every finding carries its control mapping across seven frameworks, with gap analysis in the report and retest history showing what closed and when. Generated per assessment, not assembled the fortnight before.
PCI DSS · SOC 2 · ISO 27001 · HIPAA · GDPR · NIST · CIS
Overview
Compliance mapping looks like an administrative feature right up until the first time you need it.
The moment arrives as a question, usually with a deadline attached. An auditor asks which controls a set of findings affects. A customer's vendor risk team asks for evidence of testing against a framework. An internal review asks whether a gap identified last cycle was closed, and when, and by whom.
Without mapping, answering means a manual exercise: someone reads the findings, decides which controls each one touches, builds a matrix, and cross-references it against a ticket system to establish remediation status. It takes days, it is done under time pressure, and it produces a document that is stale the moment the next assessment runs.
The underlying information already exists. Every finding has a class, a location, a severity and a remediation status. Mapping is the step that connects that to the framework language your obligations are written in, and doing it at the point the finding is created rather than at the point the question is asked is the whole feature.
One thing this page will not claim. Mapping produces technical testing evidence that supports a compliance programme. It does not deliver compliance. Compliance covers organisational controls, policy, training, governance and much else that no testing tool touches, and any vendor implying otherwise is selling something they cannot deliver.
How It Works
- Step 01
Classification happens at the finding
Every finding carries the identifiers that make it comparable and mappable: a CWE weakness class, a CVE identifier where one applies, an OWASP Top 10 2021 category, a CVSS 3.1 score with the full vector string, and a compliance object recording the controls it touches.
That classification is what allows the same finding to be presented to an engineer as a CWE, to an auditor as a control gap, and to a risk register as a scored item, without anyone re-keying it.
See Vulnerability Discovery - Step 02
Control assessment and gap analysis
The Compliance Report maps findings to controls with control assessments and gap analysis. It answers the two questions an audit actually asks: which controls are affected by what we found, and where are the gaps.
Both answers are derived from the findings rather than written up alongside them, which is what keeps them current. The mapping is regenerated with every assessment instead of being rebuilt by hand in the fortnight before a deadline.
It is worth repeating the limit here rather than only at the top of the page. This is technical testing evidence measured against a control set (the part of an audit a testing tool can genuinely answer) and not a statement that the control is satisfied in full.
See Smart Reporting - Step 03
Remediation status travels with the mapping
A finding carries open, fixed, accepted or false_positive, with updated_by, timestamps and notes on every change, plus a first_seen date.
The accepted state is the one that matters most in an audit context. Risk consciously accepted is a legitimate position, but only when it is recorded as a decision with a name, a date and a reason. Unrecorded, it is indistinguishable from a control gap nobody noticed, and an auditor has no way to tell the difference.
See Risk Prioritization - Step 04
Evidence over time
Reports include comparative trend analysis against previous scans, and retest closes findings on evidence: the exploit is re-run and the finding moves to fixed only when the attack stops working.
That combination produces something most compliance evidence lacks: not just a claim that a gap was closed, but a record of what proved it, and when.
See Dashboard - Step 05
Delivery
Compliance reports export as PDF for the audit file, HTML for interactive review, and JSON or CSV for a GRC system. Reports can be branded, filtered by severity and category, scheduled for automated delivery, and shared through time-limited links with access controls, which is how an auditor or customer gets what they need without permanent access.
Seven frameworks
- PCI DSS
- For organisations handling payment card data.
- SOC 2
- The standard enterprise assurance request in B2B software.
- ISO 27001
- The international information security management standard.
- HIPAA
- For organisations handling protected health information.
- GDPR
- For personal data of EU and UK data subjects.
- NIST
- Control families underpinning many public sector and regulated environments.
- CIS
- Benchmark and control alignment.
Capabilities
Seven framework mappings
PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST, CIS.
Compliance object per finding
Recording pci_dss, owasp_top_10 and cis associations in the API.
Control assessment and gap analysis
Control-by-control assessment in the Compliance Report, stating what the testing evidenced and what it did not reach.
CWE classification
On every finding, so a weakness stays comparable across tools and across assessments.
OWASP Top 10 2021 category mapping
With full category coverage in testing.
CVE references
Attached wherever a finding matches a published vulnerability in a fingerprinted component.
CVSS 3.1 scoring
The score and the full vector string on every finding, unmodified, for the assessor who wants to check the arithmetic.
Remediation status lifecycle
open, fixed, accepted, false_positive, with attribution, timestamps and notes.
first_seen tracking
So the age of a finding is a fact rather than an estimate.
Retest verification
Findings close when the exploit stops working, with retest history retained.
Trend comparison
Each assessment compared against the ones before it, which is how a maturity claim becomes evidence rather than an assertion.
Export formats
PDF, HTML, JSON, CSV, SARIF.
Report controls
Custom branding, filtering by severity and category, scheduled delivery via email or Slack, time-limited shareable links with access controls.
Benefits
- 01
Audit preparation stops being a project.
Control mapping and gap analysis are generated per assessment rather than assembled under deadline.
- 02
One finding serves every audience.
Engineer, auditor and risk register all work from the same object, so the versions cannot drift.
- 03
Accepted risk becomes defensible.
An attributed, dated acceptance with a stated reason is a governance artefact. It is also the answer when someone asks why a high-severity finding from two quarters ago is still open.
- 04
Remediation is evidenced, not asserted.
Retest history shows what closed and what proved it, a materially stronger claim than a closed ticket.
- 05
Multi-framework organisations stop duplicating work.
A single finding maps across every applicable framework at once, rather than being assessed separately for each.
- 06
Evidence can be shared safely.
Time-limited links with access controls mean a customer or auditor receives what they need without ongoing access to your findings.
- 07
Progress is demonstrable.
Trend comparison across assessments shows a direction of travel, which is what a maturity assessment is actually looking for.
- 08
Compliance reflects operational reality.
Because evidence, findings and remediation are captured during the assessment itself, the compliance picture is based on what is happening in practice rather than on documentation prepared for review.
A SOC 2 Type II window, six weeks out.
Illustrative example. Not a customer account.
A B2B software company is preparing for its second SOC 2 audit. The auditor has asked for evidence of vulnerability management: what testing was performed, what was found, how findings were prioritised, what was remediated, and how remediation was verified.
Previously, this took a fortnight. Scan exports were reconciled against Jira, someone decided which findings mapped to which controls, and a spreadsheet was assembled, then partially rebuilt when the auditor asked a follow-up question about two findings that had been closed without a clear reason.
- 01
A Deep assessment runs against the production platform. The Compliance Report generates with findings mapped to SOC 2 controls, control assessments and gap analysis attached.
- 02
Fourteen findings from the previous quarter appear with status fixed, each carrying the retest record: the date the exploit was re-run and the confirmation that it no longer succeeded.
- 03
Three appear as accepted, each with the person who accepted the risk, the date, and the stated reason. The auditor's follow-up question is answered by the record rather than by a conversation.
- 04
Two are open, both medium, both with first_seen dates from the current quarter and remediation in progress.
- 05
Trend comparison shows the composite risk score improving across three consecutive assessments.
- 06
The auditor receives a branded PDF through a time-limited link, filtered to the findings in scope for the audit period.
Time spent assembling evidence: the duration of a report export.
What actually changed.
Not the volume of work the company did on security. That was similar. What changed is that the record of it was generated as a by-product of doing the work, rather than reconstructed afterwards from systems that were never designed to produce it.
FAQ
Frequently Asked Questions
Which frameworks do you map to?
PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS, with control assessment and gap analysis in the Compliance Report.
Does this make us compliant?
No — it produces the technical testing evidence that supports a compliance programme, which also covers organisational controls, policy and governance that no testing tool addresses.
What about frameworks not on your list?
Findings carry CWE, OWASP and CVE classification alongside the mapped frameworks, which is usually enough for a competent assessor to map to a framework we do not cover directly.
How is remediation evidenced?
Findings carry a status with updated_by, timestamps and notes on every change, and retest re-runs the specific exploit so a finding moves to fixed only when the attack stops working.
How do we handle risk we have accepted?
It moves to accepted with the person, date and reason recorded, which is the only thing separating defensible accepted risk from overlooked risk in an audit.
Can we give our auditor direct access?
Reports can be shared through time-limited links with access controls and filtered by severity and category, so an auditor gets a version scoped to the audit for the period they need it.
Can compliance data go into our GRC system?
Yes, via JSON and CSV exports plus the REST API, with each finding carrying its CVSS score and vector, CWE class, compliance object and full status history.
How far back does the evidence go?
Every finding carries a first_seen timestamp and its full status history and reports compare against previous assessments, so the record shows when something appeared and what was decided about it rather than only a snapshot of today.
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
Four audiences, four reports, one assessment
Four report templates for four audiences, five export formats, and a trend line that means something because the methodology does not change.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
One place where the answer lives
Findings with evidence, a risk score with its breakdown, and a trend line across assessments. All in one place, for a team rather than a role.
Generate the evidence, do not assemble it
Run an assessment and export a compliance report: findings mapped to controls, with gap analysis and retest history attached.
Seven frameworks mapped · Shareable with access controls