Start with the honest distinction
There is a meaningful difference between three claims, and conflating them causes real problems in procurement:
- "Supports controls mapped to X" — the product produces evidence relevant to specific control requirements. Accurate and defensible.
- "Is X compliant" — a claim about an organisation and its whole scope, which no single product can confer.
- "Is X certified" — an assessment performed by an accredited third party, with a report to show.
Say the first. Auditors treat the second as a red flag, and the third is checkable in about a minute.
What the frameworks ask for
| Framework | Relevant area | Evidence a gateway produces |
|---|---|---|
| NIST SP 800-53 | AC-2 account management, AC-6 least privilege, AU-2/AU-12 audit events, IA-2 identification and authentication | Entitlement register, session records with named human and account used, MFA enforcement records |
| CJIS Security Policy | Advanced authentication, audit and accountability, personnel-based access | MFA at every privileged session, attributable access to CAD/RMS and evidence systems, retained session records |
| SOC 2 | CC6.1 logical access, CC6.2 registration and authorisation, CC6.3 access removal, CC7.2 monitoring | Access review packs, approval records, expiry evidence, alerting on anomalies |
| ISO/IEC 27001 | A.5.15 access control, A.5.18 access rights, A.8.2 privileged access rights | Documented grants, periodic review output, privileged account inventory |
| PCI DSS | Requirement 7 need-to-know, Requirement 8 identification, Requirement 10 logging | Per-account authorisation, unique IDs, immutable session logs |
The artefacts worth generating
Auditors ask variations of a small number of questions. Produce these as standing reports rather than assembling them under pressure:
- Entitlement register. Who can reach what, as which account, with what capabilities. This is the single most requested artefact and the hardest to fake.
- Access review pack. The register plus last-used dates, formatted for a system owner to sign. Reviews without usage data are rubber-stamped.
- Session activity report. Who connected to what, for how long, with how much evidence captured.
- Evidence integrity report. Whether every recording still matches the digest sealed at close. This is what makes the recordings evidence rather than files.
- Joiners, movers, leavers. Access granted and removed in the period, with dates, demonstrating the lifecycle actually runs.
- Exception register. Systems that cannot meet the standard, with compensating controls, owners, and review dates. Auditors trust a documented exception far more than a gap they discover.
Give the auditor a login
Exports go stale between the day you generate them and the day they are read. A scoped read-only auditor role — entitlements, session metadata, and where authorised, recording playback, with no ability to grant access or alter records — is more convincing and less work.
Auditor activity should itself be logged, which auditors generally appreciate rather than resent: it demonstrates the control applies without exception.
Retention and legal hold
Set retention per system class during design, against regulatory and legal-hold obligations, and be able to state the policy precisely. "We keep everything forever" is not a policy and creates its own exposure; "ninety days" may breach a retention requirement you have not read. Evidence-bearing systems in public safety commonly require considerably longer retention than general infrastructure. The compliance page covers the mapping in more detail.