Compliance readiness

What readiness is, in one paragraph

You select the frameworks that matter (SOC 2, ISO 27001, PCI DSS, NIST CSF, etc.). The platform expands each framework into its individual controls. For every control, NullSquare tracks what evidence currently supports it — and that evidence comes from four sources. The readiness matrix shows the rolled-up status; the readiness reports turn the matrix into something you can share with internal stakeholders ahead of a real audit.

Choosing frameworks

Framework selection happens at the organization level, in the same place as your business context. Pick the frameworks you genuinely need to support — adding more frameworks does not make the platform "more compliant", it just enlarges the control surface you have to populate evidence against.

You can change framework selection at any time; the readiness matrix recomputes when you do.

How a control gets covered

Each control draws on one or more of these evidence types. The platform shows you which type currently supports each control so you can decide whether to add more.

• Agent-tested — technical evidence produced by NullSquare assessment work. Best for controls that can be verified through testing (authentication strength, authorization checks, encryption in transit, exposure surface).
• User evidence — file-based documents your team uploads (policies, procedures, training records, vendor agreements, runbooks). Reviewed and approved by an organization member before they count.
• Integration evidence — data synced from connected providers (GitHub branch protection, Entra MFA configuration, Workspace 2-step verification). Reviewed and approved by an organization member before they count.
• Accepted risk — an explicit decision not to remediate a gap, with documented owner, rationale, approver, and optional expiry. Visible in the matrix as accepted-risk rather than passing.

The review gate

Uploaded and integration-synced evidence does not automatically pass a control. It enters the evidence library as candidate evidence, and an organization member with the right role reviews and approves it.

This is intentional. The platform can ingest data, but only your team can attest that a specific document or configuration actually demonstrates the intent behind a control. Reviewer identity, date, and notes are all preserved as part of the readiness trail.

Reading the readiness matrix

Open the Compliance area to see the matrix. Each control shows its current status (covered, partial, gap, accepted risk, out of scope), the evidence type backing it, the last reviewed date, and the next recommended action.

Drill into a control to see the underlying evidence, who approved it, and any open gaps the platform has identified.

Baseline, gap, and report runs

You drive readiness work through three kinds of runs, which are just regular assessments with compliance-tuned goals.

• Baseline assessment — establishes initial technical readiness evidence on a fresh scope.
• Gap assessment — targets the controls that currently have insufficient evidence and tries to close them.
• Report-only readiness — regenerates a readiness report from existing evidence without launching new technical work.

Readiness reports

A readiness report is a written summary of the matrix at a point in time, suitable for sharing internally or with an external advisor ahead of a real audit. It cites the evidence that supports each control, lists gaps, and identifies the most useful next steps.

Reports are reproducible — you can regenerate them after evidence changes — and they always include the limitation language below.

What readiness is not