A.5.8 Information security in project management: evidence

What A.5.8 information security in project management asks for

An auditor who asks how security is handled in projects that change systems or buy new services is testing control A.5.8, Information security in project management. The control asks the organization to integrate information security into project management, so that security risks and requirements tied to each project and its deliverables are addressed throughout the project life cycle, not added at the end. The point is timing: a security requirement identified at go-live costs far more to meet than one written into the initial scope, and an auditor will look for evidence that the organization decided this before the build started.

A.5.8 is a 2022 consolidation. It merges two 2013 controls: A.6.1.5, Information security in project management, and A.14.1.1, Information security requirements analysis and specification. The older edition treated project security and requirements analysis as separate topics. The 2022 control keeps both ideas in one place, so the organization should be able to show that security requirements are captured at project initiation and that project risks are reviewed as the work moves through its stages. Confirm the wording and implementation guidance in ISO/IEC 27002:2022 before you draft your procedure, since that document gives the detailed guidance for each Annex A control.

The difficulty is that A.5.8 applies to every kind of project. A software release, a data center refit, a new payroll outsourcing contract and a building access system upgrade all touch information in some way, yet many organizations run only their software projects through a security gate. Facilities and procurement projects often bypass the process altogether, and security is then raised late by a reviewer, a customer questionnaire or a penetration test. For your own environment, list every project category that changes systems, data flows or third-party services, then decide which security checkpoints apply to each. Keep the records that show the decision was made at initiation, at design review and before go-live.

Which projects and deliverables fall under A.5.8

A.5.8 applies to the projects that touch the ISMS scope, so the first decision is which work counts as a project at all. The cards below cover the project types, deliverables and third parties that usually pull in, and the scope boundary that decides what must pass through security review.

Internal IT and software projects

Application builds, platform upgrades and internal tools are the most obvious projects under A.5.8, but the test is whether they create or change information or systems inside the ISMS scope. A new HR system holding personal data is in scope even if a small team builds it. Check that the project register lists every initiative that changes a system in scope, not only those with a formal project charter.

Cloud migration and hosting changes

Moving workloads to a new cloud account, region or self-hosted cluster changes where information lives and who can reach it. A.5.8 expects security requirements and risks to be reviewed before the move, not after the data is copied. Confirm whether the migration plan covers identity, network paths, backups and logging in the target environment.

Supplier-delivered work

When an external firm builds, configures or operates a system for you, the project is still yours for A.5.8 purposes. Security requirements must reach the supplier's delivery team through the statement of work and acceptance criteria. Ask whether the contract requires security reviews at the same project stages as internal work, and who signs off the results.

Facilities and process change

Office relocations, new data center racks or a change to how customer records are handled can affect information security without any software change. Such projects belong in scope when they alter physical access, storage media, or the way information moves through a process. Ask the project sponsor to flag any change that touches assets, locations or handling rules listed in the ISMS.

Deliverables and third parties in the boundary

A deliverable is in scope when it processes, stores or transmits information covered by the ISMS, even if it is later handed to a customer or another party. Third parties that receive project outputs, including subprocessors and hosted components, also shape the risk picture. Map each deliverable to the ISMS scope statement and record the parties that receive or operate it.

Scope boundary and the review gate

The ISMS scope statement decides which projects must pass through security review, so a vague boundary produces either missed reviews or endless ones. Define the scope in terms of systems, locations, business units and services, then set a rule that any project touching them triggers a gate. Confirm the rule with the auditor early, because the scope is what the certification body tests against.

How an assessor tests A.5.8 in practice

This table sets out the steps an assessor typically takes to test A.5.8, what each step looks for, and the evidence requested. Read it as a sequence: the sampling and stage checks show whether security is built into projects, and the findings column shows where organizations most often fail.

Test step	What the assessor checks	Evidence requested
Sample recent projects	Selects a sample of projects that fall within the ISMS scope, including small changes and outsourced work, not only flagship initiatives	Project register or portfolio list, with start and end dates and owners
Check initiation	Whether a security requirements or risk entry is recorded when the project is approved, and whether the information security function was consulted	Project charter, intake form or ticket showing a security field or assessment
Check design	Whether security requirements were carried into design, including data classification, access needs and supplier involvement	Design documents, architecture reviews, requirement lists linked to risk entries
Check go-live	Whether security risks were reassessed before release and whether open risks were accepted by an owner	Go-live checklist, test results, risk acceptance records signed by the risk owner
Confirm review records and sign-offs	Whether reviews happened at defined project stages, with dated records and the right approvers	Meeting minutes, approval records, change tickets and their recorded decisions
Interview project managers	Whether managers know the security entry point, can explain how requirements were chosen, and know who to contact	Interview notes, and examples the manager can walk through from the sample
Trace risks over time	Whether risks recorded at initiation were revisited later or dropped without a decision	Risk register history showing status changes, reviews and closure reasons
Look for common findings	Projects with no security entry point, risks recorded but never revisited, and sign-offs given without security input	Documented nonconformities, with root cause and corrective action records for each

Implementing A.5.8 step by step

This sequence moves information security from an afterthought into the normal project routine, so that security requirements and risks are identified at initiation, checked at defined stages, carried into delivery and confirmed before go-live, and then reviewed for lessons.

Define a project security procedure and its triggers
Write a short procedure that states which projects fall under it, such as new systems, significant changes, new suppliers or new data flows, and who owns each part of the process. Name the project manager, the information security function and the system owner for each role. The procedure is done when it is approved by management, published where project staff can find it, and linked to the project intake form so that every project is asked the trigger questions. Confirm with your auditor how they expect the procedure to be evidenced.
Add security requirements and risk checks at initiation
At project initiation, the project owner records the information the project will handle, its classification, the systems and suppliers involved and the applicable legal or contractual obligations. Information security then sets baseline security requirements and runs a first risk assessment, recording the risks in the project risk register with owners and proposed treatments. The output is a completed initiation checklist and register entries that the sponsor signs off before design work begins.
Set security review points at defined project stages
Agree the stages at which security is reviewed, typically design, build readiness and pre-go-live, and put them in the project plan as gates rather than optional meetings. At each gate, the reviewer checks the design against the agreed requirements, updates the risk register and records any change in scope or data handling. The output is a dated review record for each gate that lists findings, decisions and the person who accepted any residual risk.
Build requirements into design and development
Translate the agreed requirements into design and development tasks, such as access model, logging, encryption, data retention and secure coding expectations, and track them in the same backlog or work plan as functional features. Where the project uses external developers or suppliers, the same requirements are written into the statement of work. The output is a traceable list that maps each requirement to a task and a status, which the reviewer checks at the next gate.
Carry accepted risks and requirements into testing and acceptance
Before acceptance, test that the delivered system meets the security requirements, using the test types the project has agreed, such as configuration review, access testing and vulnerability scanning. Any open findings are either fixed or formally accepted by the risk owner with a stated reason and review date. The output is a test report and an acceptance record that lists each requirement with its test result and every residual risk with its named owner.
Hand over security responsibilities to operations
Transfer the accepted requirements, residual risks and operating procedures to the team that will run the system, including monitoring, patching, access reviews and backup responsibilities. Update the asset inventory, the access rights and the supplier records to reflect the live system. The output is a handover checklist signed by the receiving operations owner, which shows that the security obligations of the project did not end with go-live.
Close the project with a post-project security review
After go-live and an agreed period of operation, review the project's security record against what happened, including incidents, changes after go-live, risks that materialized and gaps in the procedure itself. Feed lessons into the project security procedure and into the risk assessment for future projects. The output is a signed post-project review record and, where needed, a change request to the procedure, which closes the loop that auditors look for under this control.

Evidence that satisfies A.5.8 and how to keep it current

Auditors testing A.5.8 look for a trail that runs from the first project request through delivery and handover. Each artifact below proves one step of that trail, and the trail only holds if records are created during the project rather than rebuilt before an assessment.

Project security requirement records

Each project should have a dated record of the information security requirements that were identified at initiation, such as data classification, hosting location, authentication model and regulatory obligations. Auditors check that the record exists for each in-scope project, that it names an owner, and that it was created before design work began. Check that requirements trace to the classification scheme and to the relevant Annex A controls, not just to a generic checklist.

Project risk register entries

Security risks raised for a project should sit in a register with the project identifier, a description, a likelihood and impact rating, the treatment chosen, and a named risk owner. Auditors sample entries against project records to see whether risks identified at initiation were carried forward through each stage. Check that the register uses the same rating method as the organization's enterprise risk assessment.

Stage review minutes

Security should be a standing agenda item at each project gate, such as design approval, build completion and pre-release. Minutes should record who attended, which security requirements were checked, which risks changed, and what actions were assigned with due dates. Auditors look for minutes that show a decision was made, not just that a meeting occurred.

Approval records for accepted risks

When a project proceeds with a security risk that is not fully treated, the acceptance should be recorded with the rationale, the residual rating, the approver's name and role, and an expiry or review date. Auditors test whether approvers held authority under the organization's risk acceptance rules. Confirm that acceptances are reviewed when the project changes scope.

Test results tied to requirements

Security testing results should map back to the specific requirements recorded at initiation, so a reviewer can see which requirement each test verified and what it found. Results from code review, dependency scanning, configuration checks and penetration testing all count when linked this way. Check that open findings have tickets, owners and a documented disposition before release.

Handover checklists

Before a project closes or moves into operation, a handover checklist should confirm that security controls are configured, logging and monitoring are enabled, documentation is transferred, and accepted risks are passed to the operating owner. Auditors check that the checklist was signed by both the project lead and the receiving operations owner. Keep the signed copy with the project record.

How security checkpoints fit into the project life cycle

Security checkpoints work best as gates that sit inside the stages the project already runs, not as a separate security project. A.5.8 asks that information security risks tied to projects and deliverables are addressed throughout the project life cycle, so the practical design is a short set of security decisions attached to existing milestones: initiation, design approval, build completion, test exit and go-live. At each gate the project owner should be able to show what security requirements were agreed, which risks were accepted, and who accepted them. Confirm with your own project methodology which stages exist and who signs each gate, because the control does not prescribe a particular model.

For software delivery, the closely related Annex A controls do much of the detailed work. A.8.25 Secure development life cycle covers the rules a development team follows, A.8.26 Application security requirements covers how security requirements for applications are identified and approved, and A.8.30 Outsourced development covers the same expectations when a third party builds the software. Checkpoints are where these outputs are checked: a design review confirms that application security requirements were captured, and a release gate confirms that the development rules were followed. Ask each team which of these controls its gate evidence is meant to support, so that one record does not get counted twice or missed.

Teams already working from NIST SP 800-53 can use the NIST crosswalk to ISO/IEC 27001:2022 as an external reference. In that mapping, A.5.8 relates to PL-2 System Security and Privacy Plans, PL-8 Security and Privacy Architectures, SA-3 System Development Life Cycle, SA-4 Acquisition Process and SA-15 Development Process, Standards, and Tools. These relationships can help reuse design artifacts across frameworks, but they are not an equivalence claim. Confirm each mapping against your own ISMS and Statement of Applicability before relying on it in front of an auditor, since the certification body will test your documented approach, not a third-party spreadsheet.

What meeting A.5.8 costs in money and effort

This table breaks down the cost components of running A.5.8 across the project life cycle, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for scoping and for comparing quotes, since no prices or durations are supplied for these components.

Cost component	Who carries the cost	One-time or recurring, and what drives it
Procedure and template design	Security lead, project management office, legal or procurement reviewer	One-time. Scales with the number of project types and how many existing project methods must be reconciled.
Tooling for tickets and risk records	Internal IT or platform team, or implementation partner for setup	Setup is one-time, licensing or hosting recurs. Driven by whether project risks sit in the same system as tickets, such as an open-source helpdesk or ITSM tool.
Project manager time for security requirements	Project managers and product owners on each project	Recurring per project. Rises with project volume and with the share of projects touching regulated or customer data.
Security reviewer time at project stages	Internal security reviewers or an external security adviser	Recurring per review gate. Rises with the number of stage gates and the number of open risks carried between them.
Supplier and sub-contractor security review	Procurement, security reviewers, supplier contacts	Recurring per new supplier. Rises with the number of suppliers introduced into projects, which links to A.5.19 and A.5.20 work.
External testing for high-risk projects	Independent security testing provider, scoped per project	Recurring per high-risk project. Driven by the number of internet-facing or regulated systems in scope and by how risk triage is set.
Auditor sampling time	Internal evidence owner during the audit, and the certification body's auditors	Recurring each audit cycle. Drives how quickly project records can be produced, so consistent records lower it.
Reuse of templates and risk-based triage	Security lead	Cost reducer. Standard requirement sets and tiered review depth cut repeated effort on low-risk projects.

Who does what for project security under A.5.8

Your organization owns every project security decision. Clause 5 of ISO/IEC 27001 places accountability for the ISMS with top management, and A.5.8 requires that information security risks tied to projects and deliverables are addressed through the project life cycle. That means your project managers, product owners and security leads decide which security requirements apply to each project, which risks are accepted, and who signs off when a risk moves from open to accepted or closed. A partner can recommend, but the signature and the accountable name stay with you.

Security requirements: Decide which requirements apply to each type of project, such as new systems, changes to existing systems and purchases of third-party products.
Risk acceptance: Name the person who may accept a residual project risk, and record the reason and the review date.
Stage gates: Confirm who must approve a project at each review point before it moves forward.
Ownership of records: Keep the project security register, decisions and approvals inside your own systems.
Resourcing: Assign time for security reviews in project plans so the work is not dropped under delivery pressure.

Before relying on this split, confirm in writing which named roles hold each of these decisions and whether the records can be retrieved by an auditor without help from the partner.

Where organizations fall short on A.5.8

Most A.5.8 gaps come from security arriving too late, too narrowly or not at all in project work. The cards below cover the points where security requirements and risks usually drop out of a project, and what to put in place at each one so that evidence exists when an assessor asks for it.

Security review after design freeze

Many teams bring security in once the architecture is approved and the build plan is locked, so any finding means rework or a documented risk acceptance. An assessor testing A.5.8 will look for security requirements in the initial project brief and for a review at each stage gate. Close the gap by adding a security checkpoint before design approval, with a named reviewer who can change the design, not only comment on it.

No triggers for small work

Projects that are labeled as minor changes, quick fixes or proofs of concept often skip the security step entirely, even when they touch customer data or internet-facing services. Without clear triggers, that work falls outside the ISMS and leaves no record of a decision. Close the gap by defining objective triggers, such as new data types, new external connections or new suppliers, that route any project through a short security screen.

Risks recorded but not tested

Project risk registers often list security concerns that never reach the test plan, the acceptance criteria or the release checklist. An auditor sampling a project will ask how each identified risk was verified before go-live. Close the gap by giving every security risk a linked test case or acceptance criterion, and by requiring the owner to sign off on the result before release.

Supplier-built work without security terms

When a vendor or contractor delivers part of a project, security requirements are frequently left out of the statement of work, so the supplier has no obligation to meet them. The result is code or configuration that the organization cannot test against an agreed standard. Close the gap by writing security requirements, testing rights and vulnerability handling into the statement of work before award, and reviewing deliverables against them at acceptance.

No post-project security review

Once a project closes, its security decisions, accepted risks and open findings are rarely revisited, so lessons do not reach the next project. Assessors look for evidence that project outcomes feed back into the ISMS. Close the gap by running a short review at closure that records accepted risks, open findings and their owners, and by moving any unresolved items into the risk register with a review date.

Questions buyers ask about A.5.8 cost, effort and outside help

How much extra effort does information security add to each project?

The effort depends less on the control itself than on how many projects you run and how many of them touch sensitive data, systems or external parties. A small internal change to a reporting tool usually needs a short security check: a question list, a data classification decision and a note in the project record. A new customer-facing platform or a system that handles regulated data needs a fuller security requirements review, a risk assessment at design, and a check before go-live. Drivers that raise effort include the number of security-relevant projects, the number of approval gates, and how many suppliers or cloud services are involved. Ask for the cost in a written scope that lists which project types are covered and at which stages the reviews happen.

Can a small team run information security in project management without a dedicated security role?

Yes, provided the procedure is short, the trigger for a full review is clear, and someone is named to answer security questions. A small team usually keeps one checklist that every project opens at kickoff, a simple rule for which projects need a deeper review, and a standing agenda item in existing delivery meetings. The control asks that security risks are handled through the project life cycle, not that a separate security department runs each project. What a small team often lacks is time to write requirements from scratch, so reusable templates for access, logging, data handling and supplier terms carry most of the load. Confirm with your certification body how much evidence they expect for a team of your size.

How long does it take to build the project security procedure?

No fixed duration applies, because the time depends on the number of project types, how mature your current delivery method is, and whether your existing templates already ask security questions. The main drivers are inventorying the project types you run, agreeing who approves a security requirement, and connecting the review to existing stage gates or ticketing workflows. Organizations with a documented change or project process usually add the security steps faster than those starting from nothing. Ask any implementation partner for a written plan that lists the deliverables, the review points and the people whose time is needed from project managers, architects and security staff.

Can an implementation partner set up information security in project management for us?

An implementation partner can prepare the procedure, templates, ticket workflows and evidence records, but your organization must own the control and make the decisions. Under the standard, management decides the risk acceptance and the security requirements for each system, so a partner cannot accept risk on your behalf. Work that a partner commonly takes on includes drafting the procedure, configuring project and ticketing tools to hold the security checklist, and building a record format that shows each review. Work that stays with you includes approving the procedure, naming project owners, and reviewing the outcome of each project. Ask for a fixed scope listing these items before work starts.

What does the work need from project managers and delivery leads?

Project managers need to treat security as a normal project stage, with the same visibility as schedule and budget. In practice this means opening the security checklist at kickoff, recording which information and systems the project touches, flagging any supplier or cloud service, and keeping security items on the risk log. They also need to make sure security requirements survive into the delivered system, which means tracking acceptance criteria and noting open findings before go-live. Project managers do not need to perform technical testing, but they do need to know who to call and how to escalate a decision that the review cannot close.

Can a partner act as our ISO 27001 auditor for this control?

No. An implementation partner prepares systems, procedures and evidence, but only an independent auditor or certification body can assess the control and issue a certificate. Accredited certification bodies must be independent of the organizations they audit and of the parties that helped build the management system. Your certification body is a separate firm, and it checks your evidence against the requirement during its audit. Before engaging anyone, ask the certification body how it treats consultants who prepared your evidence, and confirm the rules with the body directly. The ISO certification page also explains how the accredited certification process works.

How DeployOpen prepares A.5.8 project security evidence

DeployOpen starts every A.5.8 engagement by agreeing the scope in writing before any work begins. The written scope names the projects in question, the security requirements each project must carry, the people who approve security decisions at each project stage, and the deliverables the organization will receive. The organization keeps ownership of its project governance and its controls. DeployOpen prepares the systems and records that let those controls operate. DeployOpen does not issue audit reports or certifications. An independent auditor or certification body makes that judgment, so the organization should confirm early which auditor it will use and what evidence that auditor expects to sample.

Once the scope is fixed, DeployOpen can configure self-hosted ticketing and risk workflows inside the client's own infrastructure. For example, a team might run GLPI on its own servers, with change and problem tickets used as the record of security review at each project gate, or use Zammad for requests that arrive from customers and partners. The configuration covers which ticket categories require a security reviewer, which fields capture the risk owner and accepted risks, and how a project's security requirements are linked to the tickets that deliver them. The exact capabilities of each platform should be confirmed against the version the client intends to deploy before the design is signed off.

The evidence an auditor will test for A.5.8 is a trail: security requirements recorded at project start, risks reviewed at defined stages, decisions with named approvers, and proof that the agreed controls reached delivery. DeployOpen prepares that trail as exportable records, covering project security checklists, risk registers linked to ticket histories and review minutes, and a short procedure describing how the workflow operates. Clients should ask their auditor whether sampled projects must come from a defined period, and whether a risk register kept in a separate tool needs to be reconciled with the ticketing system. Those questions shape what the workflow must store, so they belong in the scope before configuration starts.

A.5.8 Information security in project management