ISMS Manual

1. Purpose

This manual describes how the Organisation establishes, implements, maintains and continually improves its information security management system (ISMS). It is the top-level document of the library: it states what the ISMS covers, who is accountable for it, how its parts connect, and which policy, procedure, plan or template carries the detail for each topic.

It is written to follow the clause order of ISO/IEC 27001:2022 (clauses 4 to 10) so that a customer, auditor or new employee can find how each requirement is met without reading the whole library. It does not repeat the standard; it records the Organisation's own decisions.

• Give top management a single place that shows the ISMS is planned, resourced and working.
• Let any employee find the right document for a task within [two minutes] using the library map in section 8.2.
• Show an auditor or customer which document and which record evidences each ISMS requirement (Annexure B).
• Fix the vocabulary used by every other document so that terms mean the same thing everywhere.

2. Scope

This manual applies to the ISMS of the Organisation as defined in the scope statement in section 4.3. It binds all employees, contractors, consultants, interns and temporary staff, and any supplier that handles the Organisation's information under contract.

• In scope: [the Organisation's registered office, delivery centres, data centre and cloud hosting accounts], all information assets used to deliver [the Organisation's services] and all people who work in or for those locations.
• In scope: the processes in section 4.4, including processes carried out by suppliers on the Organisation's behalf.
• Out of scope: [named business units, products or sites that hold no customer or business-critical information]. Each exclusion is justified in the scope statement and reviewed at every management review.
• Out of scope: the personal devices and accounts of staff, except where they are used for Organisation business under the Mobile Device and Teleworking Policy.

3. Terms, Definitions and Documentation Structure

3.1 Terms and definitions

3.2 How the ISMS documentation is organised

The ISMS is documented in four levels. Each level is more specific than the one above and must not contradict it. Where two documents conflict, the higher level applies until the lower document is corrected.

Document numbering follows the pattern SXL-A## for policies and SXL-B## for procedures and plans. Version control, approval, distribution and retention follow the Documents and Records Management Procedure.

3.2.1 Principles for writing and keeping ISMS documents

• Every policy statement is testable: a reviewer can tell whether it was followed.
• Every procedure names an owner, a time target and the record that proves the step was done.
• Every decision the Organisation must make (a period, threshold, tool or frequency) appears once, in square brackets, in the document that owns it.
• A document that nobody follows is corrected or withdrawn; it is not left in the library.

4. Context of the Organisation

This section covers clauses 4.1 to 4.4 of the standard. It records what the Organisation is, what shapes its information security risk, who has requirements of it, where the ISMS boundary lies and which processes make up the ISMS.

4.1 Understanding the Organisation and its context

The Organisation determines the external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcomes of the ISMS. These are recorded and maintained in the Internal and External Issues and Interested Parties statement, which is the controlled source for this clause.

• External issues cover law and regulation, the threat landscape, customer and market expectations, technology change, the supply chain, and economic or geopolitical conditions.
• Internal issues cover governance, strategy, culture, people and skills, the technology estate, the standards the Organisation has committed to, and the state of vulnerability and patch management.
• The Head of Information Security refreshes the issues list at least every [12 months], before each management review, and after any major change or incident that points to an issue not yet recorded.
• Each issue is rated for its effect on the ISMS ([High, Medium, Low]) and linked to the risk, objective or control that responds to it.

4.2 Understanding the needs and expectations of interested parties

The Organisation identifies the interested parties relevant to the ISMS, their requirements, and which of those requirements become obligations or commitments the ISMS must meet. The register is held in the Internal and External Issues and Interested Parties statement. A summary of the main groups follows.

4.3 Determining the scope of the ISMS

The scope is set by considering the issues and requirements above, the interfaces and dependencies between what the ISMS covers and what it does not, and the activities performed by others on the Organisation's behalf. The scope statement is a controlled record approved by top management and reviewed at least every [12 months].

4.4 Information security management system and its processes

The Organisation has established the ISMS processes below and manages them with defined owners, inputs, outputs and measures. Their interaction is: risk assessment feeds treatment and the Statement of Applicability; treatment produces controls and objectives; operation produces records; monitoring, audit and review test the result; and improvement actions go back into planning.

5. Leadership

This section covers clauses 5.1 to 5.3. Top management owns the ISMS; the Head of Information Security runs it.

5.1 Leadership and commitment

Top management demonstrates leadership and commitment through the actions below. Each has a named evidence item so that commitment can be checked rather than assumed.

5.2 Information security policy

Top management has approved the Information Security Policy. It states the Organisation's commitment to protect the confidentiality, integrity and availability of information, to satisfy applicable requirements, and to improve the ISMS continually, and it provides the framework for objectives. It is available as documented information, communicated to all personnel at joining and every [12 months], and made available to interested parties on request.

• The policy is reviewed at least every [12 months] and after any significant change in context, risk or law.
• Topic policies in the library implement it. A topic policy cannot grant a permission the policy denies.
• Each employee and contractor acknowledges the policy in writing at joining and at each annual refresher; the record is kept by HR.
• Suppliers receive the parts of the policy relevant to their work through the contract and the Supplier Relationship Management Procedure.

5.3 Organisational roles, responsibilities and authorities

Responsibilities and authorities for roles relevant to information security are assigned, communicated and understood. The roles below apply to the whole library; individual documents add role detail where needed. The detailed policy-level roles are in the Information Security Policy.

5.3.1 Information Security Steering Committee operation

• Members: [Chief Executive Officer or delegate (chair), Head of Information Security (secretary), heads of Technology, Operations, HR, Legal and compliance, Finance, and the Data Protection Officer].
• Quorum: [the chair or delegate and at least half of the members]. A decision is recorded in minutes and an action tracker with owner and date.
• Standing agenda: status of actions from the previous meeting, risk register changes, metrics, audit and assessment results, incidents and near misses, exceptions granted, regulatory change, resourcing, and proposed changes.
• Escalation: any member may call an extraordinary meeting within [five working days] for a major incident, a high-risk finding or a significant change.

5.3.2 Segregation of duties and independence

Duties that could be misused in combination are separated, and where full separation is impractical the activity is monitored and reviewed by someone not involved. Internal audit does not audit work it designed or ran. The person who requests an access right, change or exception does not also approve it.

• Examples that must be separated: raising and approving a change; creating and approving a user account; developing and releasing code to production; initiating and approving a payment to a supplier.
• Where a small team cannot separate a duty, the Head of Information Security records the reason and the compensating control in the exceptions register.

5.3.3 Contact with authorities and special interest groups

The Organisation keeps up-to-date contact details for the authorities it may need to notify (such as the national computer emergency response team, the data protection regulator, law enforcement and sector regulators), and for specialist forums, mailing lists and professional bodies used for threat and vulnerability information. The contact list is reviewed every [six months] by the Head of Information Security. Only the incident manager, Legal and compliance or a delegate named in the Information Security Incident Management Policy may make a notification to an authority.

6. Planning

This section covers clause 6.1 (actions to address risks and opportunities) and 6.2 (objectives). Clause 6.3 (planning of changes) is covered in section 11.

6.1 Actions to address risks and opportunities

When planning the ISMS the Organisation considers the issues and interested-party requirements from section 4 and determines the risks and opportunities that must be addressed to give assurance that the ISMS can achieve its outcomes, prevent or reduce undesired effects, and achieve improvement. Actions are planned into the risk treatment plan, the objectives and the schedule in the ISMS Compliance Scheduled Activities Plan.

6.1.1 Information security risk assessment

The Organisation defines and applies a risk assessment process that sets risk acceptance criteria and criteria for performing assessments, produces consistent, valid and comparable results, identifies risks to confidentiality, integrity and availability, names risk owners, and analyses and evaluates the risks. The full method, with scales, tables and templates, is in the Risk Management Policy.

• Frequency: a full assessment every [12 months], and an assessment on any trigger event: a new service, a major change, a significant incident, a new supplier of critical services or a change in law.
• The assessment is led by the risk manager with asset owners, and results are reviewed by the ISSC.
• Results are held in the risk register and reported in the metrics pack.

6.1.2 Information security risk treatment

For each risk above the acceptance threshold the risk owner selects a treatment option, determines the controls needed, compares them with Annex A to make sure none has been overlooked, and records the decision in the risk treatment plan. The Statement of Applicability records which Annex A controls apply, whether they are implemented, and the reason for any exclusion. Risk owners approve the treatment plan and accept the residual risk in writing.

6.1.3 Opportunities

Opportunities that arise from the ISMS, such as winning customers that require evidence of assurance, reducing audit effort through automation, or consolidating tools, are recorded in the issues register and assessed by the ISSC alongside risks. An opportunity that is approved becomes an objective or a project.

6.2 Information security objectives and planning to achieve them

Objectives are set at relevant functions and levels. They are consistent with the policy, measurable, take account of requirements and risk results, are monitored, communicated and updated as appropriate. For each objective the plan states what will be done, what resources are needed, who is responsible, when it will be completed and how results will be evaluated.

Objectives are documented in the objectives register (Annexure C), approved by the ISSC, and reviewed in each management review. An objective that is missed for [two consecutive periods] triggers a root cause review under the corrective action process in section 10.

7. Support

This section covers clauses 7.1 to 7.5.

7.1 Resources

The Organisation determines and provides the resources needed for the ISMS. The annual security plan states the budget, people and tools required for the objectives and the risk treatment plan. Resource gaps that prevent a control operating are raised to the ISSC within [10 working days] and recorded as a risk if not resolved.

7.2 Competence

The Organisation determines the competence needed for people whose work affects information security performance, ensures they are competent through education, training or experience, takes action where competence is lacking, and keeps evidence.

7.3 Awareness

Persons doing work under the Organisation's control are aware of the information security policy, their contribution to the effectiveness of the ISMS including the benefits of improved performance, and the implications of not conforming. Awareness covers induction within [first week], annual refresher, role-based modules, simulated phishing at least [quarterly], and targeted communication after incidents.

• Completion is tracked by HR and reported monthly; access is suspended for staff more than [30 days] overdue on mandatory training until it is complete.
• Awareness effectiveness is measured by test scores, phishing click and report rates, and the number of security events reported by staff.

7.4 Communication

The Organisation determines the internal and external communication relevant to the ISMS. Responsibility for each is fixed in the table below; no one else makes external statements about security.

7.5 Documented information

The ISMS includes the documented information required by the standard and the documented information the Organisation has determined to be necessary for the ISMS to be effective. The approach to creating, updating and controlling it is in the Documents and Records Management Procedure.

• Creating and updating: each document has a code, title, version, owner, approver, effective date and review date, and is approved before use.
• Control: the master library is held in [the document management system] with access control, change history and a single published copy. Printed copies are uncontrolled.
• Retention: records are kept for the periods in the retention schedule of the Documents and Records Management Procedure, with a minimum of [three years] for audit and risk records unless the law requires longer.
• Protection: documents are classified under the Information Classification and Handling Policy and protected from loss of confidentiality, improper use and loss of integrity.
• External documents, such as customer requirements and standards, are identified, kept current and controlled in the same system.

8. Operation

This section covers clauses 8.1 to 8.3 and presents the library, which is how operational control is delivered.

8.1 Operational planning and control

The Organisation plans, implements and controls the processes needed to meet requirements and to carry out the actions determined in section 6. Operational control is delivered through the policies and procedures listed in section 8.2, each of which names an owner, a time target and a record. Planned changes are controlled and the consequences of unintended changes are reviewed, as set out in section 11.

• Processes are executed as documented; deviations are recorded as nonconformities or exceptions.
• Outsourced processes and the supply of externally provided products and services that are relevant to the ISMS are identified and controlled through the Supplier Relationship Management Policy and Supplier Relationship Management Procedure.
• Documented information is kept to the extent needed to have confidence that processes were carried out as planned.

8.2 Library map

The tables below list every document in the ISMS library by exact title, grouped as in the library. Policies (A-series) state the rules; procedures, processes and plans (B-series) state how. Where a policy has a matching procedure, both are shown. Annexure B shows which clause each document supports.

8.2.1 ISMS framework documents

8.2.2 Access, assets and people

8.2.3 Technology and operations: build, change and protect

8.2.4 Technology and operations: monitor, detect and fix

8.2.5 Resilience, suppliers, privacy and compliance

8.3 Information security risk assessment and treatment in operation

Risk assessments are performed at planned intervals or when significant changes are proposed or occur, taking account of the acceptance criteria, and the results are retained as documented information. The risk treatment plan is implemented and the results of treatment are retained. Treatment actions are tracked to closure by the risk manager and reviewed by the ISSC [quarterly].

9. Performance Evaluation

This section covers clauses 9.1 to 9.3.

9.1 Monitoring, measurement, analysis and evaluation

The Organisation determines what needs to be monitored and measured, the methods used to ensure valid results, when monitoring and measuring is performed, who performs it, when results are analysed and evaluated, and who does that. Each document in the library carries its own measures; the ISMS-level measures below are reported to the ISSC in the metrics pack.

When a measure falls outside target for [two consecutive periods], the owner reports a cause and a corrective action at the next ISSC meeting. Measures themselves are reviewed yearly to confirm they still show something decision makers need.

9.2 Internal audit

The Organisation conducts internal audits at planned intervals to provide information on whether the ISMS conforms to the Organisation's own requirements and the standard, and is effectively implemented and maintained. The programme covers every ISMS process and every clause of the standard at least once in each [12 months], with higher-risk areas and areas with earlier findings audited more often.

1. Plan the programmeThe internal audit lead prepares an annual programme with scope, criteria, method, frequency and auditors, approved by the ISSC in [month 1]. Output: audit programme.
2. Select auditorsAuditors are competent and independent of the area audited. Output: assignment letters.
3. Notify and prepareThe auditee is notified at least [10 working days] before. Auditors prepare checklists from the documents, the previous findings and the risk register.
4. Conduct the auditAuditors interview staff, inspect records and test controls on a sample basis, and record objective evidence.
5. ReportA written report with findings graded as major nonconformity, minor nonconformity, observation or good practice is issued within [five working days] of the closing meeting.
6. Agree actionsThe auditee proposes a correction, root cause and corrective action with dates within [10 working days]. Actions go to the tracker.
7. Verify and reportThe audit lead verifies closure and reports the programme result to top management in the management review.

9.3 Management review

Top management reviews the ISMS at planned intervals, at least every [six months], to ensure its continuing suitability, adequacy and effectiveness. The review is held as an ISSC meeting with a fixed agenda.

Minutes record the decisions, owners and dates, and are issued within [five working days]. The template is Annexure D.

10. Improvement

This section covers clauses 10.1 and 10.2.

10.1 Continual improvement

The Organisation continually improves the suitability, adequacy and effectiveness of the ISMS. Sources of improvement are audit results, incident reviews, metrics, supplier and customer feedback, benchmarking, staff suggestions and changes in the threat landscape. Improvements above [a set effort threshold, for example 10 person-days] are approved as projects by the ISSC and tracked in the action tracker.

10.2 Nonconformity and corrective action

A nonconformity can be found in an audit, a review, an incident, a supplier assessment or by any employee. The same process applies to all of them.

1. RecordThe finder logs the nonconformity in the action tracker with date, source, requirement breached and evidence. Target: within [two working days] of discovery.
2. Contain and correctThe process owner takes immediate action to control and correct it and deals with the consequences. Target: within [five working days] for major, [15] for minor.
3. Find the causeThe process owner determines the root cause using a method suited to the problem (for example five whys or a causal factor tree) and checks whether similar issues exist or could occur elsewhere.
4. ActThe owner defines corrective action, resources, owner and due date; the Head of Information Security agrees the action. Major actions go to the ISSC.
5. Verify effectivenessAfter [30 to 90 days] the audit lead or the Head of Information Security checks that the action worked and the cause has gone. Output: effectiveness note.
6. Update the ISMSIf the review shows a change is needed to the ISMS, a document, risk or control, the change is made through the Documents and Records Management Procedure and the Change Management Policy and Procedure.

11. Planning of Changes

This section covers clause 6.3. When the Organisation determines the need for changes to the ISMS, the changes are carried out in a planned manner. This applies to changes to the scope, policies, risk method, controls, roles, tools and to the ISMS documents themselves.

1. RaiseThe proposer submits a change to the Head of Information Security stating the purpose, the clauses and documents affected, and the expected benefit. Output: change request (Annexure E).
2. AssessThe Head of Information Security considers the purpose and potential consequences, the integrity of the ISMS during the change, the availability of resources, and the allocation or reallocation of responsibilities and authorities. Time target: [10 working days].
3. ApproveApproval authority depends on impact: a document wording change by the document owner; a procedure change by the Head of Information Security; a change to policy, scope, risk criteria or objectives by the ISSC, and the Information Security Policy by top management.
4. ImplementThe change is made, communicated to those affected, and training given where needed. Output: updated documents, communication record.
5. ReviewAfter [three months] the Head of Information Security confirms the change achieved its aim and caused no gap in control. Output: closure note.

12. Compliance and Monitoring

Adherence to this manual is checked through the internal audit programme, the management review and the annual review of the library. The Head of Information Security reports at each ISSC meeting the number of documents past their review date, open nonconformities against this manual, and exceptions granted. Any document more than [30 days] past its review date is escalated to the ISSC.

13. Records and Evidence

Annexure A: ISMS scope statement template

Annexure B: Clause to document map

Annexure C: Information security objectives register

Annexure D: Management review minutes template

Annexure E: ISMS change request

14. 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.

15. 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.

16. 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

• Information Security Policy
• Risk Management Policy
• Statement of Applicability
• Internal and External Issues and Interested Parties
• ISMS Compliance Scheduled Activities Plan
• Documents and Records Management Procedure
• Information Security Monitoring and Compliance Policy
• Change Management Policy and Procedure