Security Audit

Origin & evolution

Two lineages dominate. ISO/IEC 27001 certification🏵️CertificationCustomer EducationA certification programView reference → audits, conducted by accredited bodies, verify that an Information Security Management System meets the standard, with surveillance audits in the years between full recertification. The American lineage is SOC 2, built on the AICPA's Trust Services Criteria, where a licensed CPA firm issues the report.

SOC 2 made the audit-period distinction explicit. A Type I report assesses whether controls are suitably designed at a single point in time; a Type II report assesses whether they operated effectively across a window, typically six to twelve months (Drata). The shift toward Type II as the expected bar changed what evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → means. Evidence collection must begin at the start of the observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference → period, because auditors sample across the whole window and missing evidence for the early months can compromise the audit (Hicomply). The audit became a continuous discipline whose proof accrues over time.

How it works in practice

A SaaS company pursues SOC 2 Type II with a nine-month observation period. From day one, every control it claims must leave a trail: access reviews logged quarterly, change approvals recorded, incident🚨IncidentDevOps & PlatformA production incidentView reference → tickets closed with evidence. In month ten the auditor samples. They pull a random week in month two and ask for proof that the access-review control ran. If the company only started collecting evidence in month seven, that sample fails, and a control the company genuinely operates is reported as a gap because it cannot be shown. The audit verifies the compliance framework🏟️Compliance FrameworkComplianceA compliance framework (SOC 2, GDPR, etc.)View reference →'s criteria were met across the entire window, and the report it issues is what the company's enterprise customers read instead of trusting a verbal assurance.

Security audit vs. its neighbours

• Compliance framework is the standard being measured against: the Trust Services Criteria, ISO 27001 Annex A. The audit is the act of verification; the framework is the yardstick. One framework, many audits over the years.
• Security review🧐Security ReviewSecurityA security reviewView reference → is internal and continuous, run by the team for its own assurance, with no certificate. An audit is external, periodic, and produces a document others rely on. A review finds problems; an audit attests to their absence.
• Audit log policy🪵Audit Log PolicyComplianceAn audit logging policyView reference → governs the records an audit consumes. The auditor's evidence often comes straight from the logs that policy mandates. The policy makes the trail exist; the audit reads it as proof.

In the graph

In the Unified Product Graph, a security audit sits in the compliance region as the verification act. Its two defining edges run to the standard it checks: compliance_framework_verified_by_security_auditCompliance Frameworkverified bySecurity Audithierarchy records that a framework was put to the test, and security_audit_validates_compliance_frameworkSecurity AuditvalidatesCompliance Frameworkcross-domain records the result of that test. Modelling the audit as a distinct node, separate from the framework, keeps the yardstick and the act of measuring apart, so the graph can hold many audits against one framework over time and show which periods were verified and which remain unchecked.