Controls, Audits and Certification

Choosing a framework is the easy part. The hard work is implementing controls, then proving they work through audits and, where required, achieving certification.

This lesson covers the practical journey: what controls actually look like, the types of evidence auditors expect, how the audit process runs, and what a certificate does and does not mean.

Controls fall into three classic categories by how they reduce risk:

• Preventive — stop an incident from happening (MFA, firewalls, least privilege).
• Detective — reveal an incident in progress or after the fact (logging, SIEM alerts, file-integrity monitoring).
• Corrective — restore and limit damage after an incident (backups, patching, incident response).

A strong program layers all three; relying only on prevention leaves you blind when prevention fails.

Controls are also classified by their nature:

• Administrative — policies, procedures, training, access reviews.
• Technical — implemented in technology: encryption, access control, logging.
• Physical — locks, badge readers, secure facilities.

Auditors look for coverage across all three. A perfect technical control undermined by a policy nobody follows is not a real control.

Auditors evaluate controls on two dimensions:

• Design effectiveness — is the control, if it works as intended, capable of addressing the risk?
• Operating effectiveness — does it actually work, consistently, over a period of time?

A control can be well-designed on paper but fail in operation (e.g. log review that nobody actually performs). Evidence must prove both.

Audits run on evidence. For each control you must show it operates. Typical artifacts:

• Access-review records showing quarterly recertification.
• Logs and tickets proving alerts were investigated.
• Configuration exports showing encryption or MFA enforced.
• Training completion records.

Auditors sample. They pick a control, ask for proof over a period, and trace it end to end.

There are two audit layers:

• Internal audit — you (or a hired internal auditor) review your own ISMS to catch gaps before the external audit. Required by ISO 27001.
• External / certification audit — an accredited, independent body assesses you for the certificate.

Internal audits are a dry run. Finding your own nonconformities first is far cheaper than the certification body finding them.

ISO 27001 certification runs in two stages:

• Stage 1 — documentation review. The auditor checks your ISMS documents, scope, policy, risk assessment, and SoA exist and are coherent.
• Stage 2 — implementation audit. The auditor verifies controls actually operate via interviews, evidence sampling, and observation.

Pass both and you receive the certificate, typically valid three years with ongoing surveillance.

Audits produce findings, graded by severity:

• Major nonconformity — a control is absent or fundamentally failing; blocks certification until fixed.
• Minor nonconformity — a lapse that does not undermine the whole system; needs a corrective-action plan.
• Observation / opportunity for improvement — advisory, not a failure.

You respond with a corrective action plan: root cause, fix, and prevention of recurrence.

Certification is not permanent. ISO 27001 certificates run on a cycle:

• Surveillance audits — usually annually, lighter checks that the ISMS still operates.
• Recertification audit — a full reassessment, typically every three years.

This enforces that the ISMS keeps turning. Let controls lapse between audits and you risk losing the certificate at the next surveillance visit.

Mature teams avoid the audit-crunch scramble by pursuing continuous compliance: collect evidence automatically and keep controls always audit-ready.

• Automate evidence collection (access reviews, config snapshots) on a schedule.
• Monitor control drift, e.g. an S3 bucket made public, in real time.
• Treat compliance as a continuous state, not an annual project.

This is also where SOAR and compliance-automation tools pay off, turning point-in-time audits into ongoing assurance.

Sometimes a required control genuinely cannot be implemented as written, perhaps a legacy system cannot support MFA. Frameworks allow compensating controls: an alternative that meets the same risk objective.

• Document why the original control is infeasible.
• Describe the alternative (e.g. strict network isolation plus enhanced monitoring of the legacy system).
• Show it reduces risk to an equivalent level.

Auditors accept compensating controls when the rationale and equivalent risk reduction are clearly evidenced, not merely asserted.

Reason about control effectiveness from an auditor's view.

Controls, audits and certification:

• Controls are preventive, detective, or corrective by function, and administrative, technical, or physical by nature; layer all of them.
• Auditors assess both design effectiveness and operating effectiveness, and operation requires evidence over a period.
• Internal audits catch gaps before the external certification audit, which runs in Stage 1 (docs) and Stage 2 (implementation).
• Findings range from major and minor nonconformities to observations; respond with corrective-action plans.
• Certificates require surveillance and recertification audits; pursue continuous compliance to stay always audit-ready.