Cyber Compliance Plan

1. Executive Summary

This plan sets out the measures, owners and dates through which the Organisation meets its cyber security, privacy and contractual obligations for the next [12 months]. It brings together governance, risk, policy, training, technical controls, privacy, incident response, vendor oversight, monitoring and insurance in one plan so that top management can see what is required, who is doing it, how it is tested and what is left to do.

• Direction: reduce the likelihood and impact of a cyber incident to the level top management has accepted in the Risk Management Policy.
• Method: every measure in this plan traces to a requirement, a risk or an objective, and has an owner, a frequency and a record.
• Reporting: the Head of Information Security reports progress to the Information Security Steering Committee [quarterly] and to top management in the management review.

2. Purpose

The purpose of the plan is to set the minimum technical and organisational measures the Organisation maintains to protect its information and its customers' data, to detect and respond to attacks, and to demonstrate compliance to customers, regulators and auditors. It also defines how gaps are found, ranked and closed.

• Translate legal, regulatory, contractual and standards requirements into a single set of dated, owned actions.
• Set minimum baselines for technical controls so that coverage is consistent across systems.
• Prepare the Organisation to detect, report and recover from incidents within the times that apply.
• Provide the evidence for assurance requests without a scramble.

3. Scope

The plan applies to the information, systems, people, suppliers and sites in the ISMS scope in the ISMS Manual, including systems run by suppliers on the Organisation's behalf and cloud services it uses.

• In scope: corporate and production networks, endpoints, servers, cloud tenants, applications, data stores, development and test environments, identity systems, and the people who use them.
• In scope: personal data of customers, employees and other individuals held by the Organisation.
• In scope: third parties with access to the Organisation's information or systems.
• Out of scope: systems wholly owned and run by customers. The Organisation's duties for those are set in the customer contract.

4. Compliance Objectives

5. Compliance Obligations

The obligations below shape the plan. Legal and compliance maintains the full register; the entries here are the ones that set time limits or technical conditions.

6. Governance and Responsibilities

7. Risk Assessment and Management

Risk drives priority in this plan. The Risk Management Policy sets the method; the plan uses its results to decide what is done first.

• The annual risk assessment and the treatment plan are inputs. Each action in this plan that addresses a High or Critical risk is flagged and tracked to closure by the risk manager.
• Threat information received under the Threat Intelligence Policy is reviewed [monthly] by the security operations lead, and any threat that changes a risk rating is passed to the risk manager within [5 working days].
• A vulnerability that cannot be fixed in its window is raised as a risk exception with compensating controls, approved under the Risk Management Policy, with a review date no later than [90 days].
• The top [10] risks and the status of their treatment appear in each quarterly report.

8. Policies and Procedures

Each area of the plan is governed by documents in the library. Owners confirm [every 12 months] that the document is current and that its records exist.

9. Privacy Commitments

The Organisation publishes a privacy notice that states what personal data it collects, why, the legal basis or consent relied on, who receives it, how long it is kept, how it is protected and how individuals can exercise their rights and complain. The notice is owned by the Data Protection Officer and reviewed [every 12 months] or when processing changes.

• Notices are written in plain language and, where required, in the languages the audience uses.
• Consent, where used, is specific, recorded, and as easy to withdraw as to give.
• Children's data, where processed, follows the extra safeguards of the Data Protection and Privacy Policy.
• A copy of each version of the notice and the date it applied is kept.

10. Training and Awareness

Phishing simulations run [quarterly]. Staff who fail a simulation twice in [12 months] receive coaching; the campaign results go to the ISSC in aggregate.

11. Technical Controls

The baseline below is the minimum for in-scope systems. A system that cannot meet a line is recorded as a risk exception. Controls are tested and evidenced at the frequency shown.

12. Data Protection and Privacy

Personal data is handled under the Data Protection and Privacy Policy, the Data Protection and Privacy Procedure and the Data Protection Act Compliance Procedure. For the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement], the Data Protection Officer keeps a record of processing activities, assesses new processing before it begins, and decides with Legal and compliance whether a personal data breach must be notified, and to whom.

• Data minimisation: collect only what is needed; delete or anonymise when the purpose ends and the retention period has expired.
• Rights: requests from individuals are logged and answered within [30 days] or the legal time if shorter.
• Transfers: personal data moves outside its jurisdiction only after the transfer is assessed and approved by the Data Protection Officer.
• Breach: the Incident Management Procedure covers personal data breaches, with notification decisions made within [24 hours] of confirmation.

13. Incident Response and Reporting

13.1 Incident response plan

The incident response plan is the Incident Management Procedure under the Information Security Incident Management Policy. This plan adds the compliance timings and the reporting tests.

• The plan is tested by a tabletop exercise at least [twice a year] and a technical exercise at least [once a year]. Findings are tracked as actions.
• Contact lists for the team, customers, regulators, law enforcement, insurer and external forensic support are verified [quarterly].

13.2 Incident response team

13.3 Incident response phases

1. Detect and reportAnyone who notices a possible incident reports it to [the service desk or security mailbox] at once. Time target: immediately; the clock for reporting duties starts when the Organisation notices.
2. TriageThe duty analyst confirms the event, rates severity and opens the incident record. Time target: [30 minutes] for High severity.
3. ContainThe technical lead isolates affected systems and accounts, blocks indicators and preserves evidence. Time target: [4 hours] for High severity.
4. ReportThe incident manager and Legal and compliance decide which reports are due and submit them within the times below.
5. Eradicate and recoverRemove the cause, restore from clean sources, verify, and return to service with extra monitoring for [14 days].
6. ReviewHold a lessons-learned review within [10 working days]. Update risks, controls and training. Output: review report and actions.

13.4 Incident reporting

14. Continuous Reporting and Monitoring

Compliance is monitored continuously, not only at audits.

• Dashboards from the identity, endpoint, vulnerability, cloud posture and backup tools feed a compliance dashboard reviewed by the Head of Information Security [weekly].
• Deviations from the baselines raise tickets with the owner and are counted as compliance gaps until closed.
• A quarterly compliance report goes to the ISSC with the status of objectives, gaps by age and severity, incidents, exceptions, supplier status and the top risks.
• Internal audit tests a sample of controls each year against the evidence the dashboards show.

15. Vendor Management

Suppliers with access to the Organisation's information or systems are managed under the Supplier Relationship Management Policy and the Supplier Relationship Management Procedure.

16. Documentation and Reporting

• All documents in this plan are held in the document management system under the Documents and Records Management Procedure.
• Each control owner keeps the evidence the baselines call for; the Head of Information Security keeps an evidence index that links each obligation to its control, test and record.
• Evidence is stored so that it can be produced to an auditor or customer within [five working days] of a request.
• Reports to top management and regulators use the templates approved by Legal and compliance.

17. Continuous Improvement

Gaps, audit findings, incident reviews, test results and changes in obligations are entered in the compliance gap tracker (Annexure A), ranked by risk, assigned an owner and a date, and closed. The plan itself is revised [every 12 months] and whenever a requirement changes.

18. Security Posture Review

1. CollectThe Head of Information Security gathers metrics, test and audit results, incident data and supplier assessments. Time target: [15 working days] before the review.
2. ScoreEach domain in the technical controls table is scored on the scorecard (Annexure B) from 1 (not in place) to 5 (in place, tested and improving) with evidence.
3. CompareScores are compared with the previous review, the target and the objectives. Gaps are linked to risks.
4. ReportThe result and the top actions go to the ISSC and top management. Time target: [10 working days] after the review.
5. ActNew actions are logged in the gap tracker. Funding decisions are recorded.

The review is held [every 6 months] and after a major incident. An external assessment of the posture is commissioned [every 12 to 24 months] as top management decides.

19. User and Entity Behaviour Analytics

User and entity behaviour analytics means using baselines of normal activity to flag unusual behaviour by accounts, devices and services. The Organisation uses it to find compromised credentials, insider misuse and malicious automation that signature-based tools miss.

• Data sources: authentication, privileged access, email, file access, cloud audit and endpoint logs, subject to the Data Protection and Privacy Policy.
• Use cases: impossible travel, mass download, new access to sensitive data, use of dormant accounts, privilege escalation, unusual service account behaviour.
• Tuning: the security operations lead reviews false positives [monthly] and re-baselines after organisational change.
• Privacy: monitoring is proportionate, covered by the Acceptable Usage Policy, restricted to security purposes, and access to analytics output is limited to named roles.
• Response: high-confidence alerts open an incident under the Incident Management Procedure within [30 minutes].

20. Cyber Insurance

Finance lead and the Head of Information Security assess [every 12 months] whether cyber insurance is an appropriate way to share residual risk, under the Risk Management Policy.

• Cover is sized against the loss scenarios from the risk assessment: response costs, business interruption, liability to third parties and regulatory costs where insurable.
• The insurer's conditions (for example controls that must be in place, and notice times) are mapped to this plan so that the Organisation can show compliance when it claims.
• Insurance does not replace controls and does not change risk ownership.

21. Measures

22. Records and Evidence

Annexure A: Compliance gap tracker

Annexure B: Security posture scorecard

Annexure C: Compliance obligations register

23. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

24. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

25. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• ISMS Manual
• Information Security Policy
• Risk Management Policy
• Information Security Incident Management Policy
• Incident Management Procedure
• Data Protection and Privacy Policy
• Supplier Relationship Management Procedure
• ISMS Compliance Scheduled Activities Plan