Skip to main content
All measures

Measure · ISO 27001 and other standards

Check information security in projects

Bring security requirements and risks into existing project planning early. Check treatment throughout the project and in the outcome, including projects outside IT.

Accountable: Project management with business owners, operations and risk ownersReviewed

Reuse existing records

Update the existing project brief, backlog and relevant decision points. Use the leading risk method, information classes and existing supplier, change and operational rules. A separate security project plan or another risk spreadsheet is not inherently necessary.

What to do

  1. 1

    Determine requirements and risks early

    Describe purpose, outcome, affected information and assets, and internal and external participants in the existing brief. Determine protection needs and applicable requirements from business, law, contracts and leading rules. Assess risks using the existing method. Consider both the future outcome and project execution, such as project access, communication and shared documents. Record testable security criteria.

  2. 2

    Plan security work through the project

    Assign ownership, authority and necessary resources. Connect treatment to existing tasks and suitable project points where authorised people check progress and results. Establish appropriate requirements for external parties through the existing supplier process. The method can fit the project, whether a short relocation, a longer construction project or agile development.

  3. 3

    Review changes and effectiveness

    Reassess risks throughout the project and when material changes occur. At planned points, check whether security requirements have been implemented and are effective; select suitable business or technical checks. Keep results, deviations and decisions in the project record. The assigned role decides necessary rework or remaining risks under the leading method.

  4. 4

    Hand over to operations

    Transfer the rules, access, responsibilities, evidence and open points actually needed. Check with the receiving roles that they can deliver the intended operation. Handle project access and copies no longer needed under the applicable rules. Continue remaining work in the existing record and use important lessons for later projects.

Worked example

Relocation changes information protection

Fictional example: a small company moves workplaces and an archive to a new site.

Planning and execution
DecisionThe project determines protection and authorised recipients for records and transport. Physical access, suitable rooms and operational dependencies are planned early; involved suppliers receive suitable requirements.
EvidenceExisting project brief with requirements, risks, owners and checkpoints.
Checking and handover
DecisionBefore use, responsible roles check intended physical access and availability of required information. Outstanding work and new responsibilities are handed to operations.
EvidenceTraceable results and decisions in the existing project record.

Record the result

  • Existing project brief or backlog with security requirements, risks, owners and checkpoints.
  • Implemented and checked treatment with decisions on changes and deviations.
  • Traceable handover to operations with necessary rules and owned remaining work.

Common implementation mistakes

Ask about security only at the end

Derive requirements early and maintain risks and checks throughout the project.

Protect only the project outcome

Project access, external cooperation, communication and copies used can also create risks.

Require new standard forms

Update existing project material and use the leading method rather than another inventory.

Reuse the implementation across requirements

The references below show which requirements the measure contributes to.

View controls and standards
  • A.5.8 · Informationssicherheit im ProjektmanagementGerman guide

    The workflow integrates requirements, execution and outcome risks, roles, treatment and effectiveness checks across the project lifecycle including handover. It is not limited to IT projects.

  • TISAX · 1.2.3

    VDA ISA 6.0.3 · Partial overlap

    Early classification and risk assessment, derived measures, review during the project and changes support the ISA project question. Actual projects and applicable additional requirements must be addressed.

    Reference

Templates for your implementation

Related resources

Sources and further reading