Compliance mapping
AISafe tags every finding with a CWE identifier and an OWASP Top 10 category at detection. Compliance mapping matches those tags to the controls in formal control catalogues, so a security or GRC team can take audit-ready evidence from work that has already run instead of commissioning a second exercise for the auditor.
The result is a control matrix. It has one row per control, showing the findings that implicate the control, how many of them remain outstanding, and the worst severity still open.
What this is not
Compliance mapping is evidence derived from findings. It is not a compliance attestation and it is not a certification. It shows which controls the detected vulnerability classes touch, but it does not state that an organization satisfies a framework.
AISafe assesses what an application does. It cannot observe organizational, physical or procedural controls, and it never implies that one of them is in place because the application result is clean. Every export lists those control families explicitly, so that a reader does not assume coverage where none exists:
- Governance and management-system controls
- Physical security and facility access
- Personnel screening and security awareness training
- Key-management ceremonies and hardware security module operations
- Log-retention infrastructure and clock synchronization
- Vendor due diligence and third-party risk registers
What the audit tested for
Because compliance mapping starts from findings, it can only tell you about controls that a finding touches. It tells you nothing about a control that no finding reached, and from the matrix alone you cannot tell whether a control with no findings means the code is clean or that part of the application was not examined.
A source code audit records this separately. It works through a methodology checklist and records, for every check, whether it tested the check against your code, whether other work in the run already answered it, whether your application has no such surface and why, or whether the check needs a running system. Read the two together: the matrix shows what the findings implicate, and the coverage record shows what the audit set out to examine. See Coverage.
You can also tick GDPR, HIPAA, or PCI DSS when you start an audit, which adds that regime's technical checks to the checklist. These options change what the audit examines, but they do not change how you should read the results. An audit with a regime ticked still produces evidence for your auditor to read. It is not an assessment of compliance.
Frameworks covered
| Framework | Version cited |
|---|---|
| PCI DSS | v4.0.1 |
| SOC 2 | AICPA Trust Services Criteria 2017 |
| ISO/IEC 27001 | 2022, Annex A |
| OWASP ASVS | v4.0.3 |
OWASP Top 10 2021 and CWE are the detection tags underneath, and both appear in the report alongside the four catalogues.
Each link in the mapping carries a confidence label and a citation to the section of the standard that supports it, so a reviewer can check a row instead of taking it on trust. Every export includes both.
The unmapped bucket
If the catalogues cannot resolve a finding's CWE or OWASP category, AISafe lists the finding in a separate bucket, with its identifiers. AISafe never drops such a finding and never places it under a control it does not belong to.
The bucket keeps the matrix from overstating coverage. A report that silently discarded the findings it could not classify would appear to cover more than it does, and that is the one failure an auditor cannot detect from the outside.
Where to get it
Per assessment. Every assessment includes its own compliance mapping, on every plan. It is a deliverable of the work the credits paid for, the same as the finding list and the PDF report. Open the assessment and export the mapping as JSON or CSV.
Per project. The project-level posture is the same mapping aggregated across every assessment in a project, over time, so it shows an auditor a trend instead of a single snapshot. It is part of Pro. Open the project's Compliance tab and export it as CSV or as a PDF.
The PDF is the document form: a cover naming the project and the frameworks, the severity distribution, a control table per framework, the unmapped bucket, and the list of controls outside AISafe's detection surface. It is rendered when you ask for it and reflects the findings as they stand at that moment. Regenerate it after triage rather than keeping an old copy.
Two people with different assessment access in the same project will export different documents, because both exports respect the same per-assessment permissions as the rest of the product.
The PDF prints a bounded number of finding identifiers per control. When a control has more, the CSV and JSON forms carry the complete list.
Attestation letters
Attestation letters are not released yet. No letter is issued and no verification link resolves. Everything else on this page is unaffected.
An attestation letter is a dated, one-page statement that an assessment was performed: what was in scope, the methodology, a severity summary, and whether any critical finding remains open. It is a deliverable of the assessment your credits paid for, so no plan will ever charge for it.
Each letter carries a verification identifier. The identifier is derived with a server-side key, so it cannot be forged, and it resolves at a public URL that needs no AISafe account. An auditor who receives the letter can confirm it directly against AISafe rather than taking the customer's copy at face value.
Open the report and use Download PDF for the letter, or copy the verification link to send on. The link is separate from a shared report URL and does not expire with one.
Re-running an assessment produces a new completion, and AISafe issues a new identifier for each new completion. The earlier identifier still resolves, so a letter that an auditor already holds can still be verified.