Using a WBS for Complex ISO 27001 Controls

A complex ISO 27001 control rarely succeeds as one task called “implement access control” or “improve monitoring.” Such labels hide policy decisions, architecture, technology, data, training, testing and transition into operation. They also make it hard to see whether the treatment actually reduced the risk.

A work breakdown structure (WBS) decomposes a defined outcome into deliverables and manageable work packages. Used well, it gives an ISMS manager a practical bridge from risk treatment to accepted control operation. Used poorly, it becomes a long task list with no security outcome or audit trail.

This guide presents an AuditPrepared method for using a deliverable-based WBS while keeping risk owners, control owners and operational teams accountable.

Decide when a WBS adds value

A WBS is useful when implementation crosses teams, systems, locations or suppliers; has material dependencies; or requires phased acceptance. Examples include:

• introducing privileged access management;
• separating production and corporate networks;
• centralising security logging;
• redesigning joiner, mover and leaver workflows;
• deploying data-loss controls across channels;
• moving recovery capability to another region; or
• implementing a supplier assurance programme.

A simple local configuration change may need only an authorised ticket and validation. Match project control to complexity and risk.

ISO’s ISO/IEC 27001 overview identifies the standard as an ISMS requirements framework. The standard does not mandate a WBS; this is AuditPrepared implementation guidance for managing complex treatment work.

Begin with the treatment outcome

Before decomposition, define why the control is necessary. The initiation record should connect:

• the risk scenario and affected business objective;
• treatment decision and approving authority;
• intended control outcome;
• scope and exclusions;
• control owner and risk owner;
• constraints, dependencies and assumptions;
• residual-risk expectation; and
• acceptance and effectiveness method.

“Deploy a tool” is not a control outcome. A better outcome might be: “Administrative access to in-scope production services is attributable, approved, strongly authenticated, time-bound where appropriate and monitored for misuse.” The technology is one part of that result.

The risk-register guide explains how to state scenarios and ownership clearly. The Statement of Applicability builder can help organise the connection to selected controls.

Decompose by deliverable, not department

Build the first WBS level around results that must exist. For a privileged-access programme, the deliverables could be:

1. approved governance and scope;
2. authoritative identity and account population;
3. target architecture and security requirements;
4. configured service and integrations;
5. migrated accounts and removed legacy paths;
6. trained users and support capability;
7. tested control and accepted residual risk; and
8. operational monitoring and review.

Each deliverable can then be decomposed into work packages small enough to assign, estimate, monitor and accept. Department-based headings such as “IT tasks” and “Security tasks” tend to obscure integration points and shared outcomes.

Define every work package

A work package should contain more than a name and due date. Record:

• unique identifier;
• deliverable and scope;
• accountable owner;
• contributors and approver;
• inputs and dependencies;
• completion or acceptance criteria;
• required implementation evidence;
• risk if late or unsuccessful;
• planned timing and status; and
• handoff to the next package or operator.

Acceptance criteria should be observable. “Configure logging” is vague. “Forward authentication, privilege elevation and administrative action events from all in-scope platforms to the approved monitoring service, with tested alert routes and documented exceptions” is testable.

Preserve three kinds of traceability

Requirement traceability

Link the treatment decision, relevant organisational rules, legal or contractual needs and selected Annex A references to the deliverables they influence.

Delivery traceability

Link each deliverable to design decisions, changes, tests, approvals and exceptions. This shows how the result was built.

Operating traceability

Link accepted deliverables to the owner, procedure, monitoring source, recurring evidence and improvement process. This shows how project output became a sustained control.

The implementation versus operating evidence guide explains why project completion alone cannot demonstrate continued effectiveness.

Make dependencies explicit

Security projects fail at interfaces. Map predecessors and conditions such as:

• asset and account inventory quality;
• identity-provider readiness;
• procurement and supplier lead times;
• network connectivity and certificates;
• legal or employee consultation;
• maintenance windows;
• data retention and storage capacity;
• training and service-desk readiness; and
• decommissioning of legacy routes.

Do not mark a deliverable complete when its dependency remains an undocumented exception. Record interim safeguards, owner, deadline and residual risk.

Use a responsibility model that respects risk ownership

The project manager coordinates delivery but should not silently accept information-security risk. Distinguish:

• sponsor: authorises resources and resolves escalation;
• risk owner: approves treatment and accepts remaining risk within authority;
• control owner: accountable for the intended outcome;
• project manager: controls scope, dependencies, status and change;
• work-package owner: delivers and evidences a defined result;
• operator: performs the recurring control; and
• assurance role: independently tests relevant criteria.

Responsibility can be combined in a small organisation, but decision authority should remain visible. The resource provision evidence guide helps connect capacity decisions to results.

Control scope and design change

A treatment project will encounter new facts. Maintain change control that asks:

• What requirement, deliverable or dependency changes?
• Does risk increase or shift elsewhere?
• Do the Statement of Applicability or treatment plan need updating?
• Who has authority to approve the change?
• What test and evidence must change?
• Does the operational owner accept the revised result?

Agile delivery and a WBS can coexist. The WBS describes the complete outcome and deliverables; iterations can deliver and refine work packages. Keep acceptance and traceability current rather than postponing them to the end.

Plan evidence as part of delivery

Identify evidence before implementation so teams do not reconstruct it later.

Deliverable	Useful evidence	Acceptance focus
Governance	Approved scope, rules and roles	Authority and alignment with risk
Design	Architecture, requirements and decisions	Coverage and secure design
Configuration	Authorised changes and configuration state	Correct and complete deployment
Migration	Population, exceptions and legacy removal	Coverage and residual exposure
Testing	Test cases, results, defects and retests	Intended behaviour and failure handling
Transition	Training, support and monitoring handoff	Sustainable operation
Acceptance	Owner approval and residual-risk decision	Accountable conclusion

Protect evidence that contains secrets, vulnerabilities or personal information. An evidence index can point to authoritative locations without duplicating sensitive files.

Test the control as a system

Work-package completion does not prove the integrated control. Test:

• normal workflow;
• denied or invalid activity;
• exception and emergency paths;
• failure of an important dependency;
• alert generation and response;
• population completeness;
• rollback or recovery where relevant; and
• transition to routine review.

For privileged access, sample different platforms and account types. Attempt an unauthorised path safely, verify attribution, trace an alert to response and confirm a departed administrator no longer has access.

Accept, transfer and measure

Formal closure should require the control owner and operational owner to agree that:

• acceptance criteria are met;
• known defects and exceptions are recorded;
• residual risk has the right approval;
• procedures and support are in place;
• monitoring and review have owners;
• evidence retention is defined; and
• post-implementation evaluation is scheduled.

The risk owner should revisit risk after real operating results exist. Avoid claiming effectiveness on the deployment date when recurring performance has not yet been observed.

Audit questions and sampling

An auditor may ask:

• Which risk and treatment decision initiated the work?
• How was scope completeness established?
• Who approved design and residual risk?
• Which dependencies or changes affected delivery?
• How were acceptance criteria tested?
• What legacy paths or exceptions remain?
• How did the project transfer into operation?
• What evidence now shows recurring effectiveness?

Sample at least one work package from each major deliverable, then trace selected results into current operation. Include a failed test, change or exception—not only successful cases.

Pass

The WBS connected risk to deliverables, accountable owners and testable acceptance. Dependencies and changes were controlled, exceptions were authorised and subsequent records showed stable operation.

Partial

Delivery was substantially complete, but several work packages used activity-based completion and the post-implementation review had not yet produced enough operating evidence.

Fail

The project reported tool deployment as complete while account coverage was unknown, legacy access remained and no owner had accepted residual risk or recurring operation.

Common mistakes

Avoid:

• decomposing tasks before defining the security outcome;
• treating a purchased product as the complete control;
• assigning departments instead of accountable people;
• ignoring shared dependencies;
• using percent complete without accepted deliverables;
• closing exceptions through informal agreement;
• retaining design evidence but no test results; or
• ending the project without operational ownership and measures.

The practical conclusion

A WBS makes complex ISO 27001 control implementation manageable when it decomposes an approved treatment outcome into deliverables that can be owned, tested and accepted. Its value is not the diagram; it is the traceability from risk through delivery into sustained operation.

Define outcomes first, expose dependencies, plan evidence, test the integrated control and make residual-risk authority explicit. Then verify performance after transition. That turns project activity into a defensible and effective control.

The subject perspective was informed by Advisera’s article on using a WBS for complex ISO 27001 control implementation, with current ISMS purpose checked against ISO sources.