Compliance Framework Coverage

The Onam platform automatically maps every security finding to the compliance frameworks you care about — 70+ frameworks supported out of the box, including CIS Benchmarks, NIST CSF 2.0, NIST 800-53, PCI-DSS v4, HIPAA/HITRUST, ISO 27001:2022, SOC 2, GDPR, NIS2, DORA, the EU AI Act, FedRAMP, and CMMC 2.0. One finding can satisfy controls in many frameworks at once. This page covers how the mapping works, how per-control scores are calculated, what each major framework checks, and how to export an audit-ready report.

Instead of running a separate compliance scan for each framework, the platform evaluates every applicable rule once and projects the results into the framework views you need. A single failing finding on "S3 public access blocked" is reflected against PCI, HIPAA, ISO, NIST, SOC 2, and CIS simultaneously — one fix, multiple compliance gains.

How compliance mapping works

A single platform rule can satisfy controls in many frameworks at the same time. When a resource passes or fails a rule, that result updates every framework mapped to it — automatically, on every scan. There is no separate "PCI scan" or "HIPAA scan" to schedule.

The three-layer model:

1. Rules — each of the 10,000+ rules is a YAML file with a clear assertion (e.g. "S3 buckets must block public access"), versioned in the catalog.
2. Controls — every framework has its own control catalog (CIS controls, NIST control families, PCI requirements). The platform maintains a many-to-many rule-to-control mapping in policy_to_frameworks.
3. Frameworks — a framework is a curated bundle of controls. Selecting "PCI-DSS v4.0" filters results to the rules mapped to PCI-DSS controls.

Every new rule added to the catalog automatically extends coverage for every framework that includes the underlying control — frameworks are never updated one at a time.

The multiplier effect, worked example — the rule "S3 bucket public access not blocked":

One finding, eight framework citations. Fixing the bucket once closes the audit gap across every framework above.

Scoring methodology

Framework scores are deterministic — no machine learning, no fuzzy logic. You can audit the math, and so can your auditor.

Scoring is per-control first. Each control's score is computed from the rule × resource evaluations mapped to it; controls roll up to categories, and categories to the framework score:

Each evaluation lands in one of three outcomes:

The framework score maps to a three-tier badge: Compliant (80% or above), Partially Compliant (60–79%), Non-Compliant (below 60%). Scores are recalculated after every scan, and historical scores are retained — you can show your auditor a 12-month trend line for any framework.

Two nuances auditors ask about. Suppressions are auditable: a suppressed finding (with documented justification) is excluded from the score but tracked in a suppression log that exports with every report. Severity does not weight the score: a failing Critical and a failing Low each count as one failed evaluation — severity drives prioritization in the findings queue, not the compliance math.

Supported frameworks

The platform ships 70+ frameworks, spanning global standards, regional regulation, and sector-specific mandates. Coverage parity is high across clouds — most frameworks evaluate the same way against AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud, and Kubernetes.

A representative selection, grouped by region and type:

New framework requests are welcomed — most additions complete within 8 weeks. Email support@onam.io with the framework name, version, and business justification.

Coverage by cloud provider

Partial doesn't mean weak. It means the framework's full breadth includes controls not yet automated on that cloud — typically because the provider's own service catalog is narrower. The covered controls are the ones that move audit outcomes.

Framework details

CIS Benchmarks

The Center for Internet Security publishes the most widely adopted configuration benchmarks for cloud platforms. The platform evaluates every applicable control automatically — no manual configuration required.

CIS publishes new versions roughly every 12–18 months. When a new version ships, the platform adds it as a new framework option without removing the old one, so you migrate when ready — multiple versions can be active simultaneously.

NIST CSF 2.0

The NIST Cybersecurity Framework 2.0 (February 2024) organizes controls into six functions, adding GOVERN alongside the original five. Platform rules are tagged to one or more functions; a failing rule pulls down the corresponding function score.

Coverage is deepest in PROTECT — most cloud configuration findings (encryption, IAM, network) live there, which is normal for a posture platform. For RESPOND and RECOVER, the platform validates the technical preconditions: backups exist, logs are enabled, alerts route somewhere.

NIST SP 800-53 (Rev 4 and Rev 5)

The federal control catalog — 20 families, roughly 1,000 controls — and the foundation FedRAMP builds on. Both Rev 4 and Rev 5 are supported. The platform maps to the 12 most cloud-relevant families:

The eight remaining families (PE, AT, CA, PL, PM, PT, SA, SR) include controls that cannot be evaluated from cloud configuration alone — they need process, documentation, or external evidence. The platform marks these "not in scope for automated evaluation" rather than failing them silently. NIST 800-171 and CMMC 2.0 (Level 2 and Level 3) are supported as their own frameworks for CUI-handling and defense-industrial-base customers.

PCI-DSS v4.0 / v4.0.1

Required for any organization that stores, processes, or transmits cardholder data. The platform automates everything except Requirement 9 (physical access), which is inherited from your cloud provider.

The Req-9 gap is healthy: AWS, Azure, and GCP are independently audited for physical security and publish their own PCI Attestation of Compliance, which you inherit.

HIPAA and HITRUST CSF v11.3

The platform automates the HIPAA Security Rule technical safeguards (§164.312) and evidences the administrative safeguards (§164.308) that have a technical footprint:

Physical safeguards (§164.310) are inherited from your cloud provider's HIPAA-eligible BAA. HITRUST CSF v11.3 is supported as a separate framework for organizations certifying against HITRUST. Onam signs a BAA with healthcare customers on the Enterprise plan — contact legal@onam.io.

ISO 27001:2022 family

ISO 27001:2022 reorganized the control set into 93 controls across four Annex A domains. The platform also maps ISO 27002 (implementation guidance) and ISO 27017 (cloud-specific controls).

All 11 controls new in the 2022 revision are mapped, including A.5.7 (Threat Intelligence), A.5.23 (Cloud services security), A.8.9 (Configuration management), A.8.16 (Monitoring activities), and A.8.28 (Secure coding).

GDPR and privacy regulation

GDPR is a regulatory framework, not a technical checklist. The platform maps technical controls to the articles with a direct technical implementation requirement:

Articles 12–23 (data-subject rights) and 44–50 (transfers) require process outside the platform. LGPD (Brazil) and CCPA (California) follow the same technical-mapping model.

SOC 2 Type II

SOC 2 maps to the five Trust Services Criteria. Most cloud customers select Security, Availability, and Confidentiality.

Coverage of CC6 (logical access controls) is particularly deep — it maps directly to the day-to-day cloud findings auditors expect to sample.

FedRAMP and CMMC

FedRAMP builds on NIST 800-53. The platform evaluates the ~325 controls in the FedRAMP Moderate baseline and supports FedRAMP High on Government plans, producing an SSP appendix that maps your environment to each control's status. Key automated controls include AC-2 (account management), AC-6 (least privilege), AU-2/AU-9 (audit events and protection), CM-6 (configuration settings), IA-2/IA-5 (MFA and authenticator management), RA-5 (vulnerability scanning), SC-8/SC-13 (transmission and cryptographic protection), and SI-2/SI-4 (flaw remediation and monitoring). CMMC 2.0 Levels 2 and 3 reuse the same 800-171-derived control set for defense contractors.

EU operational resilience — DORA, NIS2, EU AI Act

DORA (EU 2022/2554, enforced since January 2025) is mapped across ICT risk management, incident reporting, resilience testing, and third-party risk. NIS2 (EU 2022/2555) covers critical-infrastructure cybersecurity obligations. The EU AI Act mapping draws on the AI Security engine's posture findings for Bedrock, SageMaker, Azure OpenAI, and Vertex — governance, logging, and exposure controls for AI systems.

Reports and evidence

The platform produces audit-ready output in four formats, all from the same underlying data:

Programmatic access uses the compliance API:

GET /api/v1/compliance/framework/{framework_id}/report

Every report contains the same five sections: the overall score with pass/fail breakdown; per-control results grouped by category so gaps are obvious; top failing rules with remediation steps; the trend over the last six scans; and resource-level detail per failing control with cloud-console links. The suppression log — every suppressed finding with its documented justification — exports alongside.

Report schedules

Reports deliver to email, Slack, S3, or any webhook endpoint you configure.

Custom frameworks

Beyond the built-in catalog, you can define custom frameworks by mapping your own internal controls to platform rules — useful for proprietary standards or customer-contractual requirements.

1. Navigate to Compliance → Frameworks → Create Custom.
2. Define control groups (e.g. "Internal Security Standard — Section 3 — Encryption").
3. Map each control to one or more platform rules by rule ID — a rule can serve many controls.
4. Save and run a scan — the custom framework scores alongside the built-ins.

Custom frameworks get the same per-control scoring, reporting, and export capabilities as built-in frameworks.

Frequently asked questions

Can I export a framework report for my auditor? Yes — PDF and CSV from the Compliance Reports page, JSON and live scores from the API. PDF reports include the executive summary, control-by-control breakdown, and per-resource detail.

What happens to my compliance score between scans? Scores reflect the most recent completed scan (daily by default). Run an ad-hoc scan any time to refresh — see The scan pipeline.

What if a control doesn't apply to my environment? Suppress the specific findings with a documented justification. Suppressed findings are excluded from the score and tracked in the exported suppression log — auditors see exactly what was suppressed and why.

Can I track an older framework version? Yes. Multiple versions run simultaneously (e.g. NIST 800-53 Rev 4 and Rev 5, PCI-DSS v4.0 and v4.0.1). When a new version ships, the previous one stays available so you migrate without losing history.

Are framework mappings audited? Every mapping is reviewed annually by an external compliance consultant, and the mapping rationale is stored alongside each rule's YAML — your auditor can read exactly why a rule maps to a control.

Next steps

• The scan pipeline — how findings are produced before they become compliance evidence
• Architecture overview — the Compliance engine in the context of all 29 engines
• Platform data security and tenancy — residency and isolation guarantees auditors ask about
• Book a demo — generate a framework report against a live demo account