Hands type source code on a laptop against a plain light background.

ISO/IEC 27001:2022 / IMPLEMENTED IN PROJECT WORKFLOW

Bold ideas.
Careful hands.

Information is part of every idea we build. Its protection belongs in the brief, the decisions, the delivery and the handover.

Open the working handbook

UnderstandThe purpose and the people

ProtectOwned decisions and careful work

ReviewEvidence before the next step

ImproveLearning carried forward

CARE IN
EVERY
handover.PAGE & PROCESS

HOW THE PROJECT MOVES

Protection travels
with the information.

Identify what needs protecting

Identify information, obligations and interfaces.

Choose the risk response

Assess risk and approve necessary treatment.

Put the safeguards to work

Apply access, supplier and development controls.

Authorise the protected service

Review control evidence and release authority.

Rehearse recovery, retain ownership

Test recovery and maintain agreed security ownership.

THE IMPLEMENTATION BOUNDARY

The information boundary.
The safeguards inside it.

This security handbook turns the selected requirement areas into responsibilities for the commissioned service. Its agreed scope identifies information, interfaces, participating organisations and the controls justified by risk assessment. These are original operating procedures; the published standard remains the authoritative requirements source.

This handbook maps the project workflow to ISO/IEC 27001:2022, including the 2024 climate-action amendment. Clause references identify that edition.

Standard edition and background: ISO’s official standard page .

Supplied management-system certificate reference — Management-system certification

FROM REQUIREMENT TO PRACTICE

Inspect an obligation.
Locate its safeguard.

Use these security chapters to trace a requirement into a risk decision, an assigned responsibility and evidence that the chosen measure operates. Begin at the information boundary or jump to the control decision your service needs to resolve.

CLAUSE 4 / THE PROJECT HANDBOOK

Know what needs protecting.

Information has a purpose, a place and people who depend on it.

4.1

Read the security setting

The security lead identifies the organisation’s information, services, technology, threats and operating constraints. Climate-related disruption is assessed for relevance to continuity, suppliers and physical working locations rather than presumed irrelevant to digital work.

Working evidence: Security context and relevant-issues review
Responsibility: Security lead and client sponsor

4.2

Identify the obligations

The project records requirements from clients, staff, users, suppliers and relevant authorities, then determines which the security system addresses. Contractual confidentiality, data-handling instructions and relevant climate expectations are linked to an owner.

Working evidence: Interested-party and obligations register
Responsibility: Security lead

4.3

Define the information boundary

The security scope identifies services, locations, people, assets and interfaces included in the engagement. External hosting and client systems are mapped with responsibilities, so an outsourced component does not create an unexplained gap.

Working evidence: ISMS scope and dependency boundaries
Responsibility: Accountable lead and security owner

4.4

Join the protections together

Risk assessment, access, supplier decisions, incident response, release and recovery operate as a connected management process. Their interactions and evidence are maintained so protection continues through the whole delivery lifecycle.

Working evidence: Security process map and operating records
Responsibility: Security lead

CLAUSE 5 / THE PROJECT HANDBOOK

Put security decisions in capable hands.

Care for information requires authority, time and a route to act.

5.1

Lead the protection

Leadership allocates resources and ensures security requirements are part of planning and delivery. Exceptions and significant risks reach an authorised decision maker; delivery pressure does not silently override information obligations.

Working evidence: Leadership decisions and resourcing record
Responsibility: Programme leadership

5.2

Set a policy people can use

The security policy defines the project’s direction, objectives and commitment to applicable requirements and improvement. It is controlled, communicated to contributors and made available to interested parties as appropriate.

Working evidence: Approved security policy and communication
Responsibility: Accountable lead

5.3

Give every responsibility an owner

Roles identify who administers access, assesses risk, approves releases, manages incidents and reviews system performance. Reporting routes and deputies are established without publishing sensitive technical details on the public website.

Working evidence: Security responsibility and escalation map
Responsibility: Security lead

CLAUSE 6 / THE PROJECT HANDBOOK

Choose protection from the risk.

A control earns its place by addressing a real exposure.

6.1.1

Plan for uncertainty

The team identifies risks and opportunities affecting the security system’s intended outcomes. Actions are integrated into delivery and checked for effectiveness, with attention to changes in services, suppliers, information and responsibilities.

Working evidence: ISMS risks, actions and effectiveness checks
Responsibility: Security lead

6.1.2

Assess risk consistently

An agreed method defines acceptance criteria and a consistent assessment approach. Risk owners identify confidentiality, integrity and availability exposures, assess consequences and likelihood, determine levels and prioritise treatment using the same criteria.

Working evidence: Risk method, assessments and named owners
Responsibility: Risk owners with the security lead

6.1.3

Select, justify and approve treatment

The team chooses treatment options and necessary controls, checks Annex A for omissions and records inclusion, implementation status and justified exclusions in the Statement of Applicability. Risk owners approve the treatment plan and accept remaining risk explicitly.

Working evidence: Statement of Applicability and approved treatment plan
Responsibility: Security lead and authorised risk owners

6.2

Make objectives checkable

Security objectives fit the policy, relevant requirements and assessment results. Each has an owner, resources, timing and evaluation approach; for example, the agreed recovery objective is tested rather than inferred from a backup file’s existence.

Working evidence: Security objectives and evaluation plan
Responsibility: Security owner and technical lead

6.3

Plan security-system changes

A new hosting service, supplier, integration or working arrangement is planned before changing the security system. Ownership, risk effects, dependent controls and the evidence needed to confirm the new arrangement are considered together.

Working evidence: Planned change and security impact review
Responsibility: Change authority

CLAUSE 7 / THE PROJECT HANDBOOK

Equip the people around the information.

Protection includes working knowledge, careful communication and dependable records.

7.1

Provide the means to protect

The project allocates appropriate people, secure working tools, review capacity and recovery facilities for the defined scope. Resource limitations are made visible before they undermine a selected control or agreed obligation.

Working evidence: Security resources and capability decisions
Responsibility: Accountable lead

7.2

Know who is ready for the task

Relevant competence is checked for development, administration, data handling and security review. Training or supervised work addresses gaps, and evidence shows whether the intervention enabled the person to perform the task safely.

Working evidence: Competence evidence and training evaluation
Responsibility: Discipline leads

7.3

Make everyday choices informed

Contributors understand the policy, their security contribution and the consequences of missing a requirement. Briefings cover confidential inputs, approved sharing, suspicious activity and how to report a concern promptly.

Working evidence: Security briefing and awareness record
Responsibility: Security lead

7.4

Route the right message

The communication plan defines security information, recipients, timing, responsible people and channels. Incident communications follow agreed authority and applicable duties; the public site is never used to disclose credentials or exploitable configuration.

Working evidence: Communication and escalation plan
Responsibility: Security lead and client contact

7.5.1

Keep purposeful documentation

The system holds the information needed by the standard and by effective operation: scope, policy, risk method, applicability, treatment, evidence and reviews. Detail follows scope and complexity while protecting sensitive material.

Working evidence: Controlled security record index
Responsibility: Security record owner

7.5.2

Keep versions and approvals clear

Security records identify their author, date, version and format. New policies, assessments and operating instructions are reviewed and approved before becoming the current basis for access or technical decisions.

Working evidence: Record history and approval evidence
Responsibility: Document owner and reviewer

7.5.3

Protect records through their life

Authorised people can retrieve current records, while access, distribution, changes, retention and disposal are controlled. External documents are identified and retained evidence is protected from accidental loss, inappropriate disclosure or unapproved alteration.

Working evidence: Access, retention and record controls
Responsibility: Record custodian

CLAUSE 8 / THE PROJECT HANDBOOK

Protect the work while it moves.

Risk assessment becomes a practical delivery and operating routine.

8.1

Run the agreed controls

The delivery plan turns treatment decisions into operating criteria and checks. Changes and external services are controlled, unexpected deviations are assessed, and records show that necessary activities happened before the service was released.

Working evidence: Control operation and change evidence
Responsibility: Delivery and security owners

8.2

Reassess when the picture changes

Security risk assessment is repeated at planned intervals and when significant changes occur. A new data flow, authentication method or provider prompts review before deployment; assessment results are retained with the affected scope.

Working evidence: Updated risk assessment and review trigger
Responsibility: Risk owner

8.3

Carry treatment into operation

Approved treatment actions are implemented and their results recorded. An unfinished measure remains visible with an owner and decision; it is not presented as operating simply because it appears in the design or procurement brief.

Working evidence: Treatment results and control evidence
Responsibility: Treatment owner and security reviewer

CLAUSE 9 / THE PROJECT HANDBOOK

Check protection with evidence.

Monitoring, audit and leadership review ask different, complementary questions.

9.1

Know how protection performs

The team defines what security performance and system effectiveness need measuring, the method, timing and responsible people. Results such as recovery exercises, access reviews and incident follow-up are evaluated with valid, repeatable methods.

Working evidence: Monitoring plan and evaluated results
Responsibility: Security lead and service owner

9.2.1

Audit the working system

Internal audit examines conformity with the organisation’s security arrangements and relevant standard requirements, alongside effective operation. It looks for evidence across risk decisions, actual controls and improvement rather than treating a policy as proof.

Working evidence: Audit findings and objective evidence
Responsibility: Competent impartial auditor

9.2.2

Plan impartial review and follow-up

The audit programme considers process importance and earlier findings. Scope and criteria are defined, reviewers preserve objectivity, reports reach relevant management and records retain both the programme and its results.

Working evidence: Audit programme and retained reports
Responsibility: Security lead and assigned auditor

9.3.1

Review security at leadership level

Management reviews the system at planned intervals for continued suitability, adequacy and effectiveness. The meeting considers whether the security arrangements still fit the project portfolio and operating environment.

Working evidence: Management review record
Responsibility: Programme leadership

9.3.2

Bring the complete picture

Inputs include previous actions, context and stakeholder changes, feedback, progress against objectives, performance trends, audit results and corrective work. Risk assessments, treatment progress and improvement opportunities provide a basis for decisions about resources and priorities.

Working evidence: Review input pack and trend evaluation
Responsibility: Security lead

9.3.3

Turn review into a decision

Management decides on improvements and necessary changes to the security system. Decisions are retained with responsible owners and follow-up, so the next review can judge progress and unresolved exposure.

Working evidence: Review decisions and action follow-up
Responsibility: Programme leadership

CLAUSE 10 / THE PROJECT HANDBOOK

Learn without losing the lesson.

Protection improves when problems change the way the next project runs.

10.1

Improve the whole security system

Feedback, monitoring, audit and management review drive continuing improvements in suitability, adequacy and effectiveness. Useful changes may simplify access administration, strengthen supplier checks or make recovery evidence easier to repeat.

Working evidence: Improvement backlog and effectiveness evidence
Responsibility: Security lead and programme leadership

10.2

Respond, correct and verify

A security nonconformity is controlled and its consequences addressed. Causes and similar exposures are examined, corrective actions are applied, their effectiveness is reviewed and the system is changed where needed; the event, actions and outcomes remain recorded.

Working evidence: Nonconformity, corrective action and outcome
Responsibility: Incident or corrective-action owner

ANNEX A / FOUR CONNECTED THEMES

Protection that
fits the risk.

The reference set contains 93 controls across four themes. It is not a promise that every control is required for every project. Necessary controls come from risk treatment and relevant obligations; the Statement of Applicability explains selection, status and justified exclusions. Additional controls can be necessary.

A.537 reference controls

Organisational

Decisions that protect the whole arrangement.

Information classification, approved sharing, supplier obligations, cloud use, incident responsibilities and continuity arrangements are selected against the project’s actual risks.

Examples to consider: A.5.9 asset inventory; A.5.15 access policy; A.5.19 supplier relationships; A.5.23 cloud services; A.5.24 incident preparation; A.5.30 ICT continuity readiness.

A.68 reference controls

People

Protection travels with the contributor.

Role-appropriate screening, confidentiality expectations, awareness, remote working and changes in responsibility support safe participation. Access is adjusted when somebody joins, changes role or leaves.

Examples to consider: A.6.3 awareness and training; A.6.5 responsibilities after role changes; A.6.6 confidentiality agreements; A.6.7 remote working; A.6.8 reporting security events.

A.714 reference controls

Physical

Digital information still has physical surroundings.

Workspaces, equipment and media are considered alongside the commissioned provider’s facilities. Desk arrangements, secure storage and disposal are proportionate to what is handled; responsibility for provider facilities is checked through supplier assurance.

Examples to consider: A.7.4 physical monitoring; A.7.7 clear desks and screens; A.7.9 assets away from premises; A.7.10 storage media; A.7.14 equipment disposal or reuse.

A.834 reference controls

Technological

Technical choices become verifiable safeguards.

Necessary controls can include least-privilege access, approved authentication, vulnerability handling, secure configuration, backups, logging and secure development. Their configuration is verified in the relevant environment without disclosing sensitive settings publicly.

Examples to consider: A.8.8 vulnerability management; A.8.9 configuration; A.8.13 backups; A.8.15 logging; A.8.25 development lifecycle; A.8.28 secure coding; A.8.31 separation of environments; A.8.32 change management.

Control structure: ISO/IEC SC 27, control-framework overview . The examples above are project interpretations; applicability is established in the project record.

CARE YOU CAN FOLLOW

An ambitious service.
Protection with a purpose.

Tell us which information the proposed service needs and who should be allowed to use it. We can establish its boundary, examine the risks and agree the evidence required before a protected workflow is released.

Begin your project Explore quality management