Audit-grade evidence

Most GRC tools collect evidence by overwriting the last sync. That’s fast and looks clean, but it fails an audit: there’s no record of what was true on a given date, no chain of custody, and no way to sample.

Radius360’s evidence model is append-only with explicit period coverage, attestation, and sampling. Auditors can ask “show me what M365 looked like on February 14th” and get an answer.

Why audit-grade matters

For SOC 2 Type II, ISO 27001 surveillance, and HITRUST, the auditor doesn’t just want to see that a control passed today. They want evidence that the control operated effectively across the entire audit period — typically 6 to 12 months.

That means your evidence vault needs to remember every passing and failing sync, not just the latest snapshot.

Cross-framework mapping

When an integration sync writes evidence for a finding, it writes one row per framework that finding maps to — not just the framework you happened to activate. So a single Microsoft 365 Conditional Access check produces evidence rows tagged for SOC 2 CC6.1, NIST CSF PR.AA, ISO 27001 A.9.4.2, CIS 6.7, CMMC AC.L2-3.1.5, and HIPAA 164.312(d) all at once. That's the cross-framework promise: one observation, multiple frameworks satisfied.

The Evidence Vault and Review queue scope visibility to controls under your activated frameworks, so the page only renders what you're actively assessing. If you activate ISO 27001 next quarter, every prior M365 sync's ISO-tagged rows become visible without re-syncing — they were always there.

Append-only sync model

Every deep integration sync is recorded as a row in sync_runs with a unique sync_run_id. Every piece of evidence the sync produced is tagged with that sync_run_id, the period_start, and theperiod_end the sync covered.

Evidence is never overwritten. A new sync writes a new row. The vault keeps the full history.

Period coverage

Each tenant defines one or more audit periods: a name (“SOC 2 Type II 2026”), a start date, and an end date. When evidence is collected, it’s automatically tagged with the active period.

The compliance assessment surface reads from period-tagged evidence. When you generate the audit packet, the system pulls every evidence row whose period overlaps the audit window — not just the latest snapshot.

See Audit period management for the period configuration UI.

Attestation

Every approved evidence row carries an attestation: the user who approved it, the timestamp, and the review_status (auto-approved, manually approved, or rejected). This is the “chain of custody” an auditor will ask for.

The recompute trigger that calculates control completion percentages filters by both status and review_status, so a passing-but-unreviewed row doesn’t inflate your control score.

Sampling

Auditors don’t test every row — they sample. The Audit Packet Export supports configurable sample sizes per control: pull the most recent 10 evidence rows, or a random sample of 25, or every row that failed within the period.

The export is a structured ZIP: per-control folders, with the period’s evidence rows, the auditor narrative drafted by the Audit Narrator agent, and a manifest tying everything to sync_run_ids.

Vendor inheritance — what it actually does

You don’t inherit controls; you inherit the provider’s coverage of specific control points within those controls. A SOC 2 has 60-100+ controls depending on Trust Services Criteria scope. Your subprocessor’s SOC 2 satisfies the portion of yours that depends on their infrastructure — typically 15-25% of the control surface. Your application controls, access management, change management, incident response, vendor management, personnel security, code review, and customer data handling all stay yours.

The vendor inheritance feature lets you upload subprocessor reports (SOC 2 Type II, ISO 27001, PCI DSS) once and mark the specific control points the provider covers. A vision-capable AI extractor parses the report to pull the control universe, the opinion, the in-scope TSCs, and CUECs (Complementary User Entity Controls).

For each marked control point, the provider’s attestation report becomes the evidence row, tagged is_inherited=true, with the report’s period as the evidence period. CUECs become tasks on your side — the things you have to do for the vendor’s assurance to apply.

What you save: the audit time spent re-collecting infrastructure evidence the provider already attests to. What you don’t save: any of the work for the 75-85% of your control surface that’s organizational, application-layer, or operational. The auditor will accept the provider’s report for the inherited piece and ask for your own evidence on everything else.

What an auditor sees

When you hand the auditor an Audit Packet:

• Every passing control has a chain of evidence rows across the period.
• Every row has an attestation: who approved, when, what sync produced it.
• The control points covered by a subprocessor have that subprocessor’s SOC 2 / ISO / PCI attached as evidence, with the CUECs the auditor expects you to satisfy.
• The Audit Narrator’s per-control narrative is included as the “in scope” description.
• The whole packet is reproducible — re-running the export with the same period gives the same result.