Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Policy Enforcement, Exceptions and Review
A rule nobody enforces isn’t a rule
Every policy needs a way to make it real. If people see rules broken without consequence, they learn that policies don’t matter. The most reliable enforcement is technical: the system simply won’t allow the forbidden action. Where that isn’t possible, compliance is monitored and there are consequences for breaking the rules.
Ways to enforce
| Method | Example |
|---|---|
| Technical control | MFA enforced by the identity platform; USB storage blocked |
| Automated monitoring | DLP alerts; configuration compliance scans |
| Process gate | A project can’t go live without security sign-off |
| Review and audit | Access recertification; internal audit |
| Consequences | A defined disciplinary process, agreed with HR |
Managing compliance
- Measure compliance through technical checks, audits and self-assessments.
- Investigate gaps: is it ignorance, workload, or an unworkable rule?
- Respond: train, fix the process, change the policy, or take disciplinary action.
- Track exceptions.
- Report compliance levels and trends to management.
When most people break the same rule, the rule or the process around it may be the problem.
The exception process
Sometimes a legitimate business need can’t meet a policy or standard. A formal exception is a form of risk acceptance:
- Request: the business owner states the reason and how long it’s needed.
- Risk assessment: security rates the risk and proposes compensating controls.
- Approval at a level that matches the risk.
- Time limit: an expiry date, with renewal requiring re-approval.
Example. Engineering requests an exception from the laptop encryption standard for test rigs that crash with encryption enabled. It’s approved for six months, with the rigs kept in a locked lab and holding no real customer data. At expiry, a vendor fix is in place and the exception closes.
Reviewing policies
- At least annually, and after significant change.
- Use compliance data, exceptions and incidents as evidence.
- Many exceptions to one rule? The rule may need changing.
- Re-communicate after changes and get fresh acknowledgement.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most reliable way to enforce a policy | Technical controls |
| Many staff violate the same policy | Investigate why; the policy or process may be wrong |
| Requirements for a policy exception | Risk assessment, approval at the right level, a time limit |
| Inputs to policy review | Compliance results, exceptions, incidents and changes |
| Consequences for policy violations | Defined, fair and applied consistently |
In short
- Policies work only if they're enforced: preferably by technical controls, otherwise by monitoring and consequences.
- Compliance is measured through technical checks, audits and self-assessments, and reported to management.
- Widespread non-compliance may mean the policy is unworkable; investigate the cause before disciplining.
- Exceptions are formal: risk-assessed, approved at the right level, time-limited, with compensating controls where possible.
- Disciplinary consequences must be defined, fair and applied consistently, including to senior staff.
- Policies are reviewed at least yearly and after significant changes, using compliance data and incidents as input.
Exam traps
- Unenforced policies teach people that policies don't matter.
- Granting permanent, undocumented exceptions creates hidden risk.
- When most people break a rule, fixing the rule may be the right answer.
- Technical enforcement is more reliable than relying on people to remember.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Managing compliance
1 / 9