Compliance Mapping

Connect Securitain security findings with the technical controls and frameworks they can help support.

Security teams often need to answer two different questions: what is the AWS security risk, and which control or framework requirement does this risk relate to? Securitain Compliance Mapping connects supported findings to relevant control references.

Where to find Compliance Mapping

The current view groups mapped findings by framework and control.

What Compliance Mapping does

Securitain starts with a supported technical finding and maps it to relevant control references:

IAM security finding
       ↓
Technical security category
       ↓
Relevant control mapping
       ↓
Framework context

The mapping helps explain why the finding matters to a governance or compliance program.

What Compliance Mapping does not do

The IAM compliance mapping view is finding-driven. It does not mean that every control in a framework has been tested.

Supported framework mappings

Current Securitain IAM mapping logic includes control references from the following frameworks. The exact mappings available depend on finding category.

CIS AWS Foundations Benchmark

AWS configuration and IAM security best-practice controls.

AWS Foundational Security Best Practices

AWS Security Hub Foundational Security Best Practices control context.

SOC 2

Relevant Trust Services Criteria areas related to logical access and security monitoring.

ISO 27001

Relevant access-control and information-security control mappings.

PCI DSS

Relevant access control, authentication and logging requirements.

HIPAA

Relevant technical safeguard and security-rule mappings where supported.

NIST 800-53

Relevant access-control, identification/authentication and audit controls.

MITRE ATT&CK Cloud

Threat-technique context where the current mapping supports it.

Example: MFA finding

A finding related to missing MFA can be relevant to multiple frameworks simultaneously:

Missing MFA
   ├── CIS AWS control
   ├── SOC 2 access control
   ├── ISO access / authentication control
   ├── PCI authentication control
   ├── HIPAA authentication safeguard
   └── NIST authentication control

Example: external trust

A cross-account or external-trust finding may relate to third-party access, supplier relationships, external-system access and access enforcement. The compliance mapping helps the reviewer understand the governance relevance of the AWS configuration.

Findings remain the evidence source

The compliance mapping should always link back to the technical finding. A control label by itself is not sufficient. The investigator should be able to answer:

• Which finding triggered the mapping?
• What is the affected entity?
• What evidence supports the finding?
• What severity is associated with it?
• What is the current lifecycle status?
• Is the risk active or accepted?

Accepted risk remains a mapped control gap

Securitain preserves gross technical risk semantics in compliance mapping.

Finding mapped to control
        ↓
Exception approved
        ↓
Control-related technical condition still exists

Only verified remediation or a valid false-positive classification removes the technical finding from gross-risk mapping.

Compliance mapping vs certification

Securitain does not replace the certification or attestation process.

Framework coverage

Not every framework control is an AWS technical control. Many compliance programs include HR processes, physical security, vendor management, policy approval, training and legal requirements that IAM scanning cannot prove. Therefore documentation should say: Securitain provides technical control mapping for supported cloud findings — not that Securitain checks every SOC 2, HIPAA or ISO control.

Mapped-control posture accuracy

More accurate summary metrics include: Mapped Frameworks, Affected Controls, Mapped Findings, and Critical / High Findings.

How to use Compliance Mapping

1. 1

   Select a framework

   Review which supported controls have mapped findings.

2. 2

   Expand a control

   Identify the underlying findings linked to that control.

3. 3

   Review severity

   Prioritize Critical and High technical conditions first.

4. 4

   Open the finding

   Review evidence and remediation guidance.

5. 5

   Review governance state

   Determine whether the finding is active, suppressed, exception-approved, remediated or false positive.

6. 6

   Export or report

   Use compliance reports for technical evidence and review.

Evidence for auditors and security teams

A useful control mapping should preserve the chain from framework to control to finding to affected entity to evidence to remediation or governance. This makes the technical context traceable.

Framework
    ↓
Control
    ↓
Finding
    ↓
Affected Entity
    ↓
Evidence
    ↓
Remediation / Governance

Limitations

Compliance mapping depends on:

• supported finding categories
• mapping coverage
• scan completeness
• framework version
• technical evidence available

Related guides