Control 1‑3‑1 of the Essential Cybersecurity Controls (ECC – 2 : 2024) requires organizations to build, formally document, and maintain cybersecurity policies that clearly define responsibilities, control statements, exception processes, and evidence of enforcement — this post provides a practical, step‑by‑step implementation guide for organizations following the Compliance Framework, with concrete examples for small businesses.
What Control 1‑3‑1 requires (Compliance Framework context)
At its core, Control 1‑3‑1 expects a documented policy set that maps directly to the Compliance Framework's required practices, demonstrates management approval and ownership, includes measurable control objectives, and provides a lifecycle process for review and exceptions. The policy package should be auditable: signed versions, version history, remediation timelines, and objective evidence that policies are enforced by technical or procedural controls.
Step‑by‑step implementation guide
Step 1 — Define scope, owners, and governance
Begin by drafting a policy governance table that lists each policy (e.g., Access Control, Asset Management, Vulnerability Management), the assigned policy owner (job title, not person), the approval authority (CISO or equivalent), and review cadence (typically 12 months or sooner for high‑risk policies). For small businesses, assign owners by role (e.g., IT Manager) and capture this in a single policy index document that becomes your compliance control map.
Step 2 — Write clear, measurable policy statements
Each policy should contain a purpose, scope, authority, roles & responsibilities, specific control statements, enforcement methods, and exceptions. Use measurable language: for example, "All corporate user accounts must use MFA with a hardware token or OATH TOTP authenticator; password complexity requires 12+ characters; account lockout after 5 failed attempts for 15 minutes." For device management, include: "All corporate endpoints must have EDR installed and report daily status to the central management console; critical OS patches are applied within 7 days of release, high/critical vulnerability fixes within 72 hours." Embedding exact windows for remediation and required telemetry fields makes the policy testable during audits.
Step 3 — Approve, publish, and implement version control
Formalize approval with an "approved by" signature line and a version history table (version, date, author, approver, summary of change). Publish policies where staff can access them—an intranet page or shared drive with access logging. Use a simple naming convention like "Policy‑AccessControl_v1.2_2026‑03‑30.pdf" and maintain an exceptions register (spreadsheets or a ticketing system). For small organizations, a signed PDF plus a managed Google Drive folder and an exceptions Google Sheet can be sufficient evidence if access permissions are controlled and logs preserved.
Step 4 — Implement controls and collect evidence
Policies alone are not enough — you must deploy technical or procedural controls to enforce them and collect artefacts that prove enforcement. Examples of evidence: screenshots of MDM/Intune device compliance rules, MFA enforcement settings in Azure AD or Google Workspace, CSV export of asset inventory with fields (asset_id, owner, os_version, EDR_status, last_patch_date), vulnerability scan reports showing remediation within policy windows, and training completion records for staff acknowledging the policy. For a 25‑person small business, use built‑in admin consoles (Microsoft 365 Security Center) and scheduled exports to create repeatable evidence snapshots.
Step 5 — Monitor, review, and improve
Set automated alerts for policy breaches (e.g., endpoint non‑compliance, expired certificates, failed backups) and define SLA for remediation. Schedule policy review meetings tied to your risk register and incident trend analysis; update policy language when control capabilities change (new MDM feature, cloud provider changes). Keep a continuous improvement log that documents decisions and risk acceptance — this is critical for responding to auditors who ask "why" a deviation was approved.
Real‑world small business scenarios and technical details
Scenario 1: A 10‑employee marketing agency using Microsoft 365 can meet Control 1‑3‑1 by implementing an Access Control Policy that mandates MFA via Microsoft Authenticator, uses Conditional Access to block legacy auth, and requires device compliance via Intune. Evidence = Conditional Access policy JSON, Intune compliance policy screenshot, and a user training acknowledgement. Scenario 2: A 40‑employee retail business with mixed Windows and Android devices can use an asset inventory CSV exported from a password manager or MDM with columns: asset_id, owner, asset_type, os, last_seen, encryption_status, EDR_version. For vulnerability management, use a cloud‑based scanner (e.g., Qualys or a managed service) and run weekly reports with remediation tickets linked to the exceptions register.
Compliance tips, best practices, and risks of non‑implementation
Best practices: (1) Map each policy to the specific Compliance Framework control and include a traceability matrix. (2) Use templates and plain language so staff can read and follow policies. (3) Automate evidence collection where possible (scheduled exports, APIs). (4) Maintain a single source of truth for policies and exceptions. (5) Train staff during onboarding and annually. Risks of not implementing: inconsistent control enforcement, failed audits, data breaches, regulatory fines, lost customer trust, and inability to show due diligence in post‑incident investigations. A small business that lacks documented controls will struggle to prove timely patching, asset ownership, or access enforcement—common root causes of breaches.
In summary, implementing Control 1‑3‑1 under the Compliance Framework is a practical exercise in clear policy drafting, technical enforcement, documented approvals, and repeatable evidence collection — start with a policy index, write measurable control statements, automate enforcement where possible, and maintain a review cycle and exception register so you can demonstrate compliance and reduce organizational risk.
