How integrations map to framework controls

How mapping works

When a deep or standard integration collects evidence, Radius360 tags that evidence with the specific framework controls the evidence satisfies. Tags come from a maintained mapping library that Radius360 updates as framework versions evolve.

The mapping library is curated, not inferred. Every integration has been reviewed against every supported framework to determine which of its data types satisfy which controls. When NIST CSF v2.0 released, for example, every integration's mapping was re-audited rather than auto-translated from v1.1.

Three-step flow:

1. Integration sync produces an artifact (e.g., Okta MFA enforcement configuration)
2. The mapping library returns the list of controls that artifact satisfies across every supported framework (e.g., SOC 2 CC6.1, NIST CSF 2.0 PR.AA-03, CIS v8 6.3, HIPAA 164.312(d))
3. The artifact is stored in the Evidence Vault with those control tags, and every affected framework assessment updates in real time

A worked example

Your Okta integration syncs. One of the checks it runs is whether an active Okta policy enforces MFA. That single check writes evidence for:

• SOC 2 CC6.1: Logical access security
• SOC 2 CC6.2: User registration and authorization
• NIST CSF 2.0 PR.AA-03: Users, services, and hardware are authenticated
• CIS v8 6.3 and 6.4: MFA for externally exposed applications and for remote network access
• HIPAA 164.312(d): Person or entity authentication

You collected evidence once. Six controls across four frameworks update. This is the single biggest quiet efficiency in Radius360 and the reason a deep integration "feels" more powerful than its surface description suggests.

The mapping matrix

The full integration-to-control mapping matrix is large (46 integrations times the control libraries of 30+ frameworks), but the pattern is predictable. Each integration produces between 5 and 50 distinct artifact types; each artifact type maps to between 1 and 12 controls depending on the framework breadth.

Each integration card on the Integrations page summarizes what the integration feeds into Radius360. To see exactly which controls a piece of evidence is tagged to, open it in the Evidence Vault.

When mappings overlap

Two integrations will often satisfy the same control from different angles. Okta and Microsoft Entra both produce MFA enforcement evidence. Radius360 does not treat the control as double-satisfied or weighted higher because of duplicate sources: it is satisfied if at least one piece of current evidence exists.

However, the evidence vault retains both artifacts. An auditor pulling the evidence for SOC 2 CC6.6 will see the Okta proof and the Entra proof side by side, with timestamps, source references, and collection metadata for each.

Overriding a mapping

The default mappings are curated and correct for most tenants. You can override in two directions:

• Remove a mapping. If an artifact from an integration genuinely does not prove a control in your specific environment (e.g., the Okta MFA config doesn't cover all admin paths because you have a secondary admin system), remove that specific control tag from the artifact. Document why in the artifact's notes field.
• Add a mapping. If an integration collects evidence that our default mapping does not credit toward a specific control, you can add the tag manually. Radius360 logs the override with your justification so auditors see you made the call deliberately.

Overrides are per-tenant. Your overrides do not affect the default mapping for other tenants in your practice.

Related reading: Framework assessments, Deep vs standard.