한국어
A.5.8

Information security in project management

Organizational controlsCheckpoints 5Evidence 5Cases 5

Control objective

This control requires information security to be embedded in project management processes regardless of the project's type, scale, or methodology, so that security risks arising during a project and in its deliverables are identified and addressed early. It calls for security to be considered from project initiation and planning, for security requirements to be defined, applied, and verified at each stage, and for responsibilities to be clearly assigned. The aim is to reduce the cost and risk of retrofitting controls after the fact and to ensure projects produce outcomes that meet the organization's risk acceptance criteria.

Key checkpoints

  1. Are information security activities (risk identification, requirements definition, review points) explicitly integrated into the project management process/methodology?
  2. Is an information security risk assessment performed at project initiation/planning, with results reflected in the project plan?
  3. Are the security requirements to apply defined according to project type/scale, including a determination of whether personal or regulated data is handled?
  4. Are information security roles/responsibilities assigned within the project, with security review/approval at key stages (gates/milestones)?
  5. At project closure, is fulfillment of security requirements confirmed, and are residual risks and deliverables handed over to the operations organization?

Implementation guidance

  • Update the project management process/checklists so that information security is a mandatory activity from initiation, and apply this to both development and non-development projects.
  • Perform an information security risk assessment early in the project to identify threats/vulnerabilities/impacts, and integrate the resulting risks into the project risk management and treatment plan.
  • Define security and privacy requirements suited to the nature of the project (new system introduction, outsourcing, cloud migration, data migration, and similar) and reflect them in requirement specifications and design.
  • Place security review gates at each project stage to confirm requirement fulfillment at design/build/test/transition-to-operations points, with an approval step where needed.
  • Clearly assign information security and privacy roles/responsibilities in the project organization, and include contractual security requirements where external personnel or suppliers participate.
  • At project closure, verify that security requirements were met, and document residual risks/open items/security deliverables and hand them over to the operations/maintenance organization.

Evidence

  • Project management process/methodology/checklists that incorporate information security activities
  • Per-project information security risk assessment results and risk treatment plans
  • Project security requirement definitions/specifications (including privacy and regulatory requirements)
  • Stage-by-stage security review/gate approval records and meeting minutes
  • Project closure reports and residual-risk/security-deliverable handover documents

Nonconformity examples

  • The project management process does not define information security activities, so whether security is considered depends on each project owner's discretion.
  • Security requirements are reviewed only just before system go-live/transition, causing rework and schedule delays.
  • Security procedures are applied only to development projects and not to non-development projects such as reorganizations, data migrations, or cloud transitions.
  • The early project risk assessment is performed only as a formality, and the identified risks are not reflected in the project plan or treatment actions.
  • At project closure, residual risks and security deliverables are not handed over to the operations organization, creating a security management gap in the operations phase.

Source

Source/limitation: Control numbers, titles, and theme classification are based on the publicly available list of ISO/IEC 27001:2022 Annex A. The explanatory text (control objective, key checkpoints, implementation guidance, evidence, nonconformity examples) and the attribute classification are original material written by this collection for practical reference; they are not the normative text of the ISO/IEC 27001:2022 or 27002:2022 standards. For certification, verify against a licensed copy of the standard.
On this page
Item info
SetA.5
Key checkpoints5
Evidence5
Cases5