OWASP, PCI-DSS, ISO 27001, SOC 2, NIST 800-53, HIPAA and GDPR coverage should be a deterministic projection of your findings - not a quarterly spreadsheet exercise.
Compliance reporting is usually a translation job done by hand. Someone takes this quarter's findings, decides which control each one violates, pastes the result into a framework template, and signs it. The document is stale the day after it ships, because the findings underneath it have already moved. Worse, the mapping itself is a human judgement call, which is exactly the kind of artifact an auditor knows to probe. The fix is not a better spreadsheet. It is to stop maintaining the map by hand at all.
apPosture treats the framework mapping as a deterministic projection of the findings. Every finding already carries a vulnerability class and, where available, a CWE. From those two facts the control mappings are computed - not authored - against OWASP Top 10 (2021), PCI-DSS v4.0, ISO/IEC 27001:2022, NIST SP 800-53 Rev. 5, the HIPAA Security Rule, GDPR, and the SOC 2 Trust Services Criteria. Change the findings and the compliance picture recomputes itself. Nobody re-maps anything.
The mechanism is a single curated table keyed on CWE. A finding's CWE resolves to one OWASP Top 10 category, and that category fans out to the specific clauses it violates in every other framework at once. The mapping is reference data an auditor can read line by line; it is never asked of the language model. Here is what a single confirmed SQL injection (CWE-89) projects to:
Because the fan-out is computed, it is identical every time and for every finding of that class. There is no drift between the report a developer sees and the one an auditor receives, and no quarter where someone forgets that injection also touches HIPAA's integrity safeguard. The human cost of the old process was never the typing; it was the inconsistency. Two analysts map the same finding to different clauses, the same analyst maps it differently in March and in June, and the gaps only surface under audit pressure. Replacing judgement with a lookup removes that whole category of error.
Switch the input and the output changes deterministically. A broken-access-control finding such as an insecure direct object reference (CWE-639) resolves to OWASP A01 and lights up an entirely different set of clauses. The table below shows two finding classes side by side across the frameworks apPosture supports:
| Control | SQL injection (CWE-89, A03) | IDOR / broken access (CWE-639, A01) |
|---|---|---|
| OWASP Top 10 | A03:2021 Injection | A01:2021 Broken Access Control |
| PCI-DSS v4.0 | Req 6.2.4 - injection protection | Req 7.2.1 - least-privilege access control |
| ISO 27001 | A.8.28 - secure coding | A.5.15 - access control |
| NIST 800-53 | SI-10 - input validation | AC-3 - access enforcement |
| SOC 2 TSC | CC7.1 - vulnerability detection | CC6.1 - logical access security |
| HIPAA | §164.312(c)(1) - integrity | §164.312(a)(1) - access control |
| GDPR | Art 32(1)(b) - integrity of processing | Art 32(1)(b) - confidentiality of processing |
When a finding carries no usable CWE, the classifier falls back to a keyword match on the finding name, and only then to the least-assumptive bucket (security misconfiguration). The point is that the rule is fixed and inspectable. The same input always yields the same controls, which is the property an auditor actually wants to verify.
A map of which controls are touched is only half of compliance. The other half is a defensible pass rate. apPosture derives one from the same reference data. The full set of curated clauses across every OWASP category is the control universe - the denominator. A control fails when it carries at least one open finding. The score for a framework is simply the passing controls over the universe, and the letter grade uses the same bands as the posture engine: A at 90 and above, B at 80, C at 70, D at 60, F below.
Because the denominator is derived from the very same FRAMEWORK_MAP that decides which control a finding fails, a clause counted as failing is always a member of the universe it is scored against. The numerator and denominator cannot drift apart, so the percentage is reproducible rather than negotiated.
A self-updating compliance map is a powerful thing and a dangerous one, because it will faithfully amplify whatever findings feed it. If the scanner raises a control failure on a heuristic - a route that merely responded, a header that merely looked wrong - then the deterministic projection will dutifully report that failure across all seven frameworks and an auditor will chase ghosts in every one. The determinism does not make the finding true. It only makes the consequences consistent.
That is why this layer sits on top of an evidence-first engine, not the other way around. A control is only marked failing when the finding under it was proven - an in-band leak, a differential, a benign arithmetic or timing oracle - rather than guessed. The mapping table is curated and auditable; the model is used only for the narrative business-impact statement, and even that has a deterministic fallback. Strip the marketing away and the claim is narrow and testable: the compliance map recomputes itself because it is computed, and it stays trustworthy because nothing reaches it that was not first proven.
The payoff is operational. The day a developer fixes the SQL injection and the finding closes, Req 6.2.4, A.8.28, SI-10, CC7.1, §164.312(c)(1) and Article 32 all flip back to passing in the same recompute - no quarterly exercise, no re-mapping, no stale signature. The spreadsheet that used to go stale the day after it was signed is replaced by a projection that is current the moment a scan finishes.