ISO 27001 A.8.30: Retain security oversight of outsourced development

What A.8.30 requires in practice

Annex A control A.8.30 states that the organisation should direct, monitor and review activities related to outsourced system development. Handing development to another party moves the work, not the accountability. The receiving organisation remains responsible for the security of what it ends up operating.

Directing means setting expectations before work starts: security requirements, development rules and the evidence expected at suitable stages. Monitoring means following progress and watching for concerns while the work is under way. Reviewing means examining what is delivered and how it was produced before acceptance.

The outputs are agreements that carry the security expectations, oversight records during delivery, acceptance evidence, and clarity on ownership, licensing and access arrangements. International and distributed delivery arrangements are covered in the same way. Applicability follows risk treatment and the Statement of Applicability.

Agree expectations before work begins

Define the information-security requirements, relevant development rules and evidence expected at suitable stages. A requirement to deliver secure software needs a more specific interpretation before it can guide design or acceptance. Clarify how the supplier should raise concerns, obtain decisions and communicate changes to the agreed scope.

Connect these expectations with supplier agreements and application security requirements. Address relevant ownership, licensing and access arrangements. The organisation should understand what it will receive and what rights or dependencies affect future maintenance, rather than discover those limitations after delivery.

Monitor the work at meaningful points

Choose review points where the organisation can influence a decision before it becomes expensive to change. Relevant activities may include design review, review of important implementation decisions and examination of test outcomes. Oversight should focus on the work's risk, not merely the percentage of planned tasks marked complete.

Identify who inside the organisation can evaluate the evidence or obtain competent support. A supplier report cannot provide meaningful assurance if nobody understands its scope and limitations. Ask about unresolved findings, exceptions and dependencies, including relevant subcontracted work where it forms part of the delivery chain.

Why oversight of outsourced development matters to the business

Outsourcing is often chosen for speed or specialist skills, but the organisation still answers to customers if the delivered software exposes their information. Without oversight, weaknesses in code, dependencies or access arrangements can arrive unnoticed and surface long after the supplier has moved on. Active direction and review reduce rework, protect intellectual property and make disputes less likely, because expectations were explicit. They also give the business a defensible answer when customers ask how bought-in development is controlled. At audit, oversight records show that outsourcing sits inside the ISMS rather than outside it.

How to implement A.8.30

Treat the supplier as an extension of your own team for security purposes. The steps below show a practical order. Keep oversight proportionate to the importance of the work and the supplier's track record, while still ensuring that someone on your side owns the relationship. Involve procurement early, so the agreement carries the expectations before the first day of work.

1. Define the security requirements and development rules the supplier must follow, and what evidence you expect and when.
2. Place them in the agreement, alongside provisions on ownership, licensing and access to environments and code.
3. Agree how the supplier raises concerns, obtains decisions and reports scope changes.
4. Set checkpoints during delivery, such as design review and progress against requirements.
5. Review samples of the work, not only the final product, to see how it was built.
6. Examine deliverables against the requirements and testing evidence before acceptance.
7. Control the supplier's access to your systems and remove it when work ends.
8. Record lessons and feed them into the next supplier selection.

Illustrative construction example: a project-reporting portal

Illustrative software example: handover without maintenance capability

A hypothetical software business outsources a component of its service. The supplier provides a working build, but the handover lacks an agreed account of dependencies and the resources needed for future maintenance. The business initially assumes that receiving the executable file completes the security responsibility.

The parties clarify the required delivery materials, rights and maintenance responsibilities, then verify that authorised staff can use the agreed handover. The review also addresses how vulnerabilities will be reported and corrected after delivery. This reduces an avoidable dependency without claiming that every contract must include identical source-code escrow provisions.

Control access and information during delivery

External developers may need access to repositories, environments or representative information. Define what is necessary and protect it through the relevant controls. A delivery deadline does not justify unrestricted production access or an unexamined copy of live customer information.

Coordinate changes in supplier personnel and the end of the engagement with access review. Check that the organisation retains the necessary materials and that temporary accounts or copies are handled appropriately. Oversight should cover the conditions in which work is performed as well as the final software artifact.

Accept evidence, not a promise of perfection

Common nonconformities with A.8.30

Typical findings show trust placed in the supplier in place of oversight. They usually arise when the contract was signed by procurement and nobody in technology followed up, so an auditor asks to see how a recent outsourced project was directed and reviewed.

• A requirement to deliver secure software with no specific expectations behind it.
• No checkpoints during delivery, so oversight began only at handover.
• Supplier access to environments not controlled or not removed after completion.
• Ownership, licensing or source access arrangements left unclear.
• Delivered code accepted without evidence of testing against requirements.