Project Information Security Checklist: [Project name]
A stage-by-stage checklist that builds information security into a
project from idea to closure: security requirements, risk assessment,
privacy by design, supplier and cloud checks, testing and sign-off
gates. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.5.8
(information security in project management), with guidance from
ISO/IEC 27002:2022, and links to clauses 6.1.2 and 8.2 (risk
assessment). Where a project changes the ISMS itself, clause 6.3
(planning of changes) also applies through the ISMS change plan.
Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | DOC-ISMS-046 (template); project copy: [PRJ-SEC-NNN] |
| Version | [1.0] |
| Status | [Draft / In progress / Closed] |
| Owner | [@project-manager] |
| Approvers/reviewers | [@security-contact], [@isms-manager], [@dpo], [@project-sponsor] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.8, 6.1.2, 8.2); ISO/IEC 27002:2022 |
| Next scheduled review | At each gate in section 4; template reviewed every 12 months |
| Project | [Project name and ID] |
| Project type | [Software / Infrastructure / Cloud adoption / Outsourcing / M&A / Facility / Other] |
| Security tier | [Tier A high / Tier B standard / Tier C light] (section 2.2) |
Approvals
| Gate | Role | Name | Decision | Date |
|---|
| G1 Initiation | Security contact | [@security-contact] | [Pass / Pass with conditions / Hold] | YYYY-MM-DD |
| G2 Design | Security contact and DPO | [@security-contact], [@dpo] | [Pass / Pass with conditions / Hold] | YYYY-MM-DD |
| G3 Go-live | Security contact and system owner | [@security-contact], [@system-owner] | [Pass / Pass with conditions / Hold] | YYYY-MM-DD |
| G4 Closure | ISMS manager | [@isms-manager] | [Closed / Open items transferred] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change |
|---|
| 0.1 | YYYY-MM-DD | [@author] | Checklist opened at project start |
| 1.0 | YYYY-MM-DD | [@author] | Gate G1 passed |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |
Contents
1. Purpose and when to use
This checklist ensures that information security risks are identified
and treated as part of every project at [Organization name], whatever the
project method (waterfall, agile, hybrid). It turns the organization's
policies into concrete project tasks and records the security decisions
made at each stage.
Use this checklist for any project that does one or more of the
following:
- introduces, replaces or significantly changes an information system,
application, cloud service or network;
- collects, uses or shares new categories of personal data, or uses
existing personal data for a new purpose;
- brings in a new supplier with access to information or systems;
- changes a physical site that holds information or equipment;
- combines or separates organizations, business units or systems (M&A,
divestment, reorganisation).
Routine changes inside an existing system follow the change process
(ops/change-request) instead. Changes to the ISMS itself follow the ISMS
change plan (DOC-ISMS-025).
2. Project profile and security tier
2.1 Project profile
| Field | Value |
|---|
| Project name and ID | [Name, PRJ-NNN] |
| Sponsor | [@sponsor] |
| Project manager | [@project-manager] |
| Security contact | [@security-contact] |
| System owner after go-live | [@system-owner] |
| Business objective | [One or two sentences] |
| Information involved and highest classification | [Public / Internal / Confidential / Restricted] |
| Personal data involved | [None / Staff / Customers / Special categories] |
| Internet-facing component | [Yes / No] |
| Suppliers involved | [Names or "none"; supplier register IDs] |
| Cloud services involved | [Cloud service register IDs] |
| Planned go-live | YYYY-MM-DD |
2.2 Security tier
| Tier | Criteria (any one is enough) | Mandatory checklist items |
|---|
| Tier A, high | Restricted or Confidential data at scale; special category personal data; internet-facing production system; critical business process (BIA DOC-ISMS-120); new Tier 1 cloud service; M&A | All items marked A, B and C |
| Tier B, standard | Confidential data in limited volume; personal data of staff or customers in limited volume; new Tier 2 cloud service or supplier | Items marked B and C |
| Tier C, light | Internal or Public data only; no personal data beyond user accounts; no new supplier with system access | Items marked C |
Tier assigned: [A / B / C], by [@security-contact] on YYYY-MM-DD.
Reason: [short reason].
3. Roles
| Role | Responsibility in the project |
|---|
| Project sponsor | Accepts residual project risks within authority, funds required controls, decides at Hold gates |
| Project manager | Owns this checklist, plans security tasks in the schedule, collects evidence |
| Security contact | Advises on requirements and design, reviews evidence, decides gate outcome from the security side |
| Data protection officer or privacy lead | Privacy by design review, DPIA decision and review |
| System owner (future) | Accepts operational responsibility, confirms that run-time controls and procedures are ready |
| Architects and engineers | Implement security requirements, threat model, secure configuration |
| Procurement and legal | Supplier due diligence and contract security terms |
| ISMS manager | Ensures the project updates ISMS records (asset inventory, risk register, SoA references) |
4. Stages and security gates
| Gate | Question | Evidence required | Possible outcomes |
|---|
| G1 Initiation | Do we know the information at stake, the tier and the security requirements? | Sections 2 and 5 complete | Pass, Pass with conditions, Hold |
| G2 Design | Are risks assessed, privacy designed in, and the design and suppliers acceptable? | Section 6 complete, risk log entries, DPIA decision | Pass, Pass with conditions, Hold |
| G3 Go-live | Have security tests passed, are findings treated or accepted, and is operations ready? | Section 7 and 8 complete, test reports, acceptance records | Pass, Pass with conditions, Hold |
| G4 Closure | Are ISMS records updated and every open item owned outside the project? | Section 9 complete | Closed, Closed with transferred items |
"Pass with conditions" means the project may continue, but each condition
has an owner and a due date in the risk log (section 11). A Hold returns
the project to the same stage until the security contact and sponsor
agree it can move on.
5. Stage 1 checklist: initiation
Status values: Done, Not applicable (with reason), Open.
| ID | Check | Tier | Status | Evidence or note |
|---|
| S1-01 | Security contact assigned and named in the project charter | C | [Done / Open] | [Charter reference] |
| S1-02 | Information involved identified and classified (data/data-classification-policy) | C | [ ] | [ ] |
| S1-03 | Personal data screening done: types, data subjects, purposes | C | [ ] | [ ] |
| S1-04 | Security tier assigned (section 2.2) | C | [ ] | [ ] |
| S1-05 | Legal, regulatory and contractual requirements identified from the legal register DOC-ISMS-014 (for example data protection law, sector rules, customer contracts) | B | [ ] | [ ] |
| S1-06 | High-level security requirements written: access control, logging, encryption, availability, retention, backup | B | [ ] | [Requirements list reference] |
| S1-07 | Availability and recovery needs agreed with the business (recovery time and recovery point objectives) | B | [ ] | [ ] |
| S1-08 | Security tasks and effort included in the project plan and budget (tests, reviews, tooling) | B | [ ] | [ ] |
| S1-09 | Initial threats and risks noted in the project risk log (section 11) | B | [ ] | [ ] |
| S1-10 | Interfaces with other ISMS processes noted: change, supplier, cloud, BCP | A | [ ] | [ ] |
6. Stage 2 checklist: planning and design
| ID | Check | Tier | Status | Evidence or note |
|---|
| S2-01 | Security risk assessment performed with the organization's method (DOC-ISMS-010) and recorded in section 11 | B | [ ] | [ ] |
| S2-02 | Threat model completed for the solution (security/threat-model) | A | [ ] | [ ] |
| S2-03 | Privacy by design review completed (compliance/privacy-by-design-review): data minimisation, purpose, retention, rights | B | [ ] | [ ] |
| S2-04 | DPIA screening done; full DPIA completed where required by law or policy (compliance/dpia) | B | [ ] | [DPIA reference or screening result] |
| S2-05 | Security requirements detailed and traceable to design items (authentication, authorisation, input validation, logging, encryption, secrets, backups) | B | [ ] | [ ] |
| S2-06 | Architecture reviewed by the security contact: network zones, exposure, identity integration, data flows | A | [ ] | [Design review record] |
| S2-07 | Cloud services categorised and approved under DOC-ISMS-044 | B | [ ] | [Cloud service register IDs] |
| S2-08 | Suppliers assessed (compliance/supplier-security-assessment) and security terms included in contracts | B | [ ] | [Supplier register IDs] |
| S2-09 | Outsourced development requirements applied where code is written by a third party (isms/outsourced-development-security) | A | [ ] | [ ] |
| S2-10 | Secure development rules confirmed for in-house development (isms/secure-development-policy) | B | [ ] | [ ] |
| S2-11 | Access model defined: roles, privileged access, joiner, mover and leaver process | B | [ ] | [ ] |
| S2-12 | Data migration plan includes integrity checks and protection of data in transit and in test environments | A | [ ] | [ ] |
| S2-13 | Test plan includes security tests appropriate to the tier (section 7) | B | [ ] | [ ] |
| S2-14 | Risk treatment decisions approved by the risk owner; residual High risks escalated per DOC-ISMS-010 | B | [ ] | [ ] |
7. Stage 3 checklist: build, procure and test
| ID | Check | Tier | Status | Evidence or note |
|---|
| S3-01 | Systems configured to the secure configuration baseline (isms/secure-configuration-baseline) | B | [ ] | [ ] |
| S3-02 | Secrets stored in the approved secrets manager, none in code or tickets | B | [ ] | [ ] |
| S3-03 | Static and dependency scanning run in the build pipeline; findings triaged | B | [ ] | [ ] |
| S3-04 | Vulnerability scan of the deployed environment before go-live | B | [ ] | [ ] |
| S3-05 | Penetration test or equivalent independent test, scope agreed with the security contact (security/pentest-report) | A | [ ] | [ ] |
| S3-06 | Security requirements verified by test (access control, logging, encryption) | B | [ ] | [ ] |
| S3-07 | Test data: no production personal data in test unless masked or explicitly approved | B | [ ] | [ ] |
| S3-08 | Logging and monitoring integrated with the central platform (DOC-ISMS-064) | A | [ ] | [ ] |
| S3-09 | Backups configured and a restore tested (isms/backup-restore-test-log) | A | [ ] | [ ] |
| S3-10 | Supplier deliverables checked against contract security terms | B | [ ] | [ ] |
| S3-11 | Open findings recorded with severity, owner and due date; Critical and High findings fixed or accepted per DOC-ISMS-010 | B | [ ] | [ ] |
8. Stage 4 checklist: go-live and transition
| ID | Check | Tier | Status | Evidence or note |
|---|
| S4-01 | Go-live change approved through the change process (ops/change-request) | C | [ ] | [Change ID] |
| S4-02 | System owner named and has accepted operational responsibility | C | [ ] | [ ] |
| S4-03 | User accounts provisioned by role; project and test accounts removed or disabled | B | [ ] | [ ] |
| S4-04 | Privileged accounts registered and under privileged access controls | B | [ ] | [ ] |
| S4-05 | Operating procedures written (isms/security-operating-procedure) | A | [ ] | [ ] |
| S4-06 | Incident response contacts and playbooks updated for the new system | A | [ ] | [ ] |
| S4-07 | Business continuity and DR documents updated (DOC-ISMS-121, ops/disaster-recovery-plan) | A | [ ] | [ ] |
| S4-08 | Users and support staff trained on security-relevant functions | B | [ ] | [ ] |
| S4-09 | Customer or regulator notifications made where required by contract or law | B | [ ] | [ ] |
| S4-10 | Decommissioning of replaced systems planned, including data migration verification and secure disposal | B | [ ] | [ ] |
9. Stage 5 checklist: closure
| ID | Check | Tier | Status | Evidence or note |
|---|
| S5-01 | Asset inventory updated with new or changed assets (DOC-ISMS-012) | C | [ ] | [ ] |
| S5-02 | Open project risks transferred to the main risk register (DOC-ISMS-016) with owners | B | [ ] | [ ] |
| S5-03 | Open vulnerabilities transferred to the vulnerability remediation tracker (DOC-ISMS-072) | B | [ ] | [ ] |
| S5-04 | Statement of Applicability references updated where new controls or evidence were introduced (DOC-ISMS-011) | A | [ ] | [ ] |
| S5-05 | Supplier register and cloud service register updated | B | [ ] | [ ] |
| S5-06 | Project accesses for external parties revoked | B | [ ] | [ ] |
| S5-07 | Replaced systems decommissioned and data securely deleted, with records | B | [ ] | [ ] |
| S5-08 | Security lessons learned recorded and sent to the ISMS manager for the continual improvement register (DOC-ISMS-088) | C | [ ] | [ ] |
10. Additional checks by project type
10.1 Software development
| ID | Check | Stage |
|---|
| SW-01 | Secure coding standard agreed (security/secure-coding-standard) and code review includes security | 2 |
| SW-02 | Software supply chain: dependency policy, software bill of materials, signed builds (security/supply-chain-security) | 3 |
| SW-03 | Separation of development, test and production environments | 2 |
| SW-04 | Security acceptance criteria included in the definition of done for features | 2 |
10.2 Infrastructure and network
| ID | Check | Stage |
|---|
| INF-01 | Network segmentation and firewall rules reviewed (DOC-ISMS-063) | 2 |
| INF-02 | Capacity and resilience design meets agreed recovery objectives | 2 |
| INF-03 | Hardening and patch level verified before connection to production | 3 |
| INF-04 | Remote administration paths secured with MFA and logging | 3 |
10.3 Cloud adoption
| ID | Check | Stage |
|---|
| CLO-01 | Shared responsibility matrix completed (DOC-ISMS-044 section 3) | 2 |
| CLO-02 | Data location and transfer assessment completed | 2 |
| CLO-03 | Cloud exit approach recorded (DOC-ISMS-076) | 2 |
| CLO-04 | Posture monitoring enabled before go-live | 3 |
10.4 Outsourcing and managed services
| ID | Check | Stage |
|---|
| OUT-01 | Supplier security agreement with right to audit and incident notification (DOC-ISMS-068) | 2 |
| OUT-02 | Supplier staff access defined, least privilege, logged | 3 |
| OUT-03 | Service monitoring and reporting set up (A.5.22) | 4 |
| OUT-04 | Exit and transition plan agreed, including return and deletion of data | 2 |
10.5 Mergers, acquisitions and divestments
| ID | Check | Stage |
|---|
| MA-01 | Security due diligence of the target before signing: incidents, certifications, open findings, legal exposure | 1 |
| MA-02 | Interim connectivity rules: no network trust between organizations until assessed | 2 |
| MA-03 | Identity integration plan, removal of inherited dormant and shared accounts | 3 |
| MA-04 | ISMS scope impact assessed and communicated to the certification body where the certified scope changes (DOC-ISMS-002, DOC-ISMS-095) | 4 |
| MA-05 | For divestments: data separation, access removal and transfer of records agreed | 3 |
10.6 Facility and office projects
| ID | Check | Stage |
|---|
| FAC-01 | Physical security requirements applied (DOC-ISMS-055) | 2 |
| FAC-02 | Equipment moves logged, media protected in transit | 4 |
| FAC-03 | Old premises cleared, equipment disposed securely (DOC-ISMS-057) | 5 |
11. Project security risk log
| Risk ID | Description | L | I | Score and level | Treatment | Owner | Residual L x I | Residual level | Status |
|---|
| PRJ-RSK-001 (Example) | Customer personal data copied to the test environment during migration | 4 | 4 | 16 High | Masked data sets only; DPO approval for any exception | Project manager | 2 x 4 = 8 | Medium | Treated |
| PRJ-RSK-002 (Example) | Outsourced developer introduces vulnerable dependencies | 3 | 4 | 12 High | Dependency scanning in the pipeline, contract clause on secure development | Engineering lead | 2 x 3 = 6 | Medium | Treated |
| PRJ-RSK-003 (Example) | Go-live date forces release with open penetration test findings | 3 | 3 | 9 Medium | Fix Critical and High findings before release; Medium findings within 30 days | Sponsor | 2 x 3 = 6 | Medium | Accepted by risk owner and department head |
| PRJ-RSK-004 (Example) | New SaaS provider has no customer-managed encryption keys | 2 | 3 | 6 Medium | Accept, provider encryption at rest and contract terms judged sufficient | System owner | 2 x 3 = 6 | Medium | Accepted by risk owner and department head |
11.1 Worked example: Quillmere Health Systems patient portal
(Example) Quillmere Health Systems runs a project to add a patient
self-scheduling portal to its clinical scheduling service. The portal is
internet-facing and processes patient personal data on behalf of
hospitals, so the project is Tier A. At G1 the security contact (one of
the 3-person security team) adds requirements for MFA for hospital
administrators, rate limiting, audit logging and data minimisation. At G2
the DPIA screening shows a full DPIA is needed because of health data at
scale; the hospitals as controllers are consulted through the account
teams. The threat model finds an account enumeration risk, treated by
generic error messages. At G3 the penetration test reports 0 Critical,
1 High and 4 Medium findings; the High finding is fixed and retested,
and the 4 Medium findings are accepted by the system owner and the
department head with a 30-day fix plan. At G4 the portal is added to the asset inventory, two residual
risks move to the main risk register, and the SoA evidence references for
A.8.25 to A.8.29 are updated.
12. Size tiers
| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|
| Typical projects (Example) | New product features, a new SaaS tool, moving the analytics platform to a new managed database | Patient portal, colocation hardware refresh, new hospital integrations | ERP migration across plants, OT network modernisation, acquisitions in new countries |
| Security contact | The ISMS manager (0.5 FTE, Head of Engineering Operations) or a senior engineer | One of the 3-person security team per project | Security business partner per business line from the 14-person security office |
| Checklist form | Checklist copied into the project ticket epic; gates as ticket approvals | Checklist in the project management tool, gates in the steering meeting | Gates embedded in the portfolio governance process, automated reminders, dashboard of gate compliance |
| Tier distribution (Example) | Most projects Tier B or C; platform changes Tier A | Clinical data projects Tier A | Tier A for OT, M&A and ERP; local projects Tier B or C |
| Privacy | DPO function outsourced, consulted for Tier A and B | In-house privacy lead, DPIA for all health data projects | Group privacy office with country privacy leads |
| Assurance | Internal auditor (outsourced or a trained peer independent of the projects) samples 2 closed projects per year | Internal audit samples 4 projects per year | Internal audit samples per site and business line; portfolio office reports gate compliance quarterly |
13. Records and evidence
| Record | Proves | Owner | Location | Retention (Example) |
|---|
| Completed project checklist with gate approvals | Security was addressed at each stage | Project manager | [Project repository] | Life of system plus 3 years |
| Project security risk log | Risks were assessed with the organization's method and treated | Project manager | [Project repository, then risk register] | Life of system plus 3 years |
| Threat model, privacy by design review, DPIA | Design decisions considered security and privacy | Security contact, DPO | [Security and privacy repositories] | Life of system plus 3 years (DPIA as required by law) |
| Security test reports and finding acceptances | Security requirements were verified | Security contact | [Test repository] | 3 years |
| Supplier assessments and contracts | Third parties met requirements | Procurement | [Supplier records] | Life of contract plus 6 years |
| Closure record with transferred items | Residual risks and findings continued to be managed | ISMS manager | [ISMS records] | 3 years |
| Portfolio gate compliance report (medium and large tiers) | The control operates across projects | Portfolio office | [Governance reports] | 3 years |
Reference this checklist in the Statement of Applicability (DOC-ISMS-011)
against A.5.8 and in isms/control-evidence-matrix.
14. References
| Reference | Edition (checked 2026-11-01) | Use |
|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html | Current | A.5.8; clauses 6.1.2 and 8.2 (6.3 only where the project changes the ISMS); related controls A.5.23, A.8.25 to A.8.30 |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Guidance on security in project management |
| ISO/IEC 27005:2022, https://www.iso.org/standard/80585.html | Current | Risk assessment guidance for project risks |
| ISO/IEC 27701:2025, https://www.iso.org/standard/85819.html | Current | Privacy information management (privacy by design context) |
| NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 | February 2022; a Rev. 1 draft was published December 2025, check for a final version | Optional secure development practices for software projects |
| Related templates | | compliance/privacy-by-design-review, compliance/dpia, security/threat-model, isms/secure-development-policy, isms/outsourced-development-security, isms/cloud-services-security-policy, compliance/supplier-security-assessment, compliance/risk-register, security/pentest-report, ops/change-request, isms/control-evidence-matrix |
Standard and licence note
Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control
A.5.8 and clauses 6.1.2 and 8.2), ISO/IEC 27002:2022 and ISO/IEC
27005:2022. Control and clause numbers are cited with original short
labels; the checklist items, tiers, gates and examples are original text,
and no text from ISO/IEC standards is reproduced. Obtain the official
standards from ISO, IEC or your national standards body. NIST SP 800-218
is a US government publication cited by name and version. Check the
current edition of each reference before use.