Third-party security: an operating model from selection to exit

Tier suppliers by business impact

High-impact providers include identity, cloud, payment, code, data and operational dependencies. Use deeper review for services that can create broad outage or privileged access.

Maintain an owner and dependency record. Procurement should not be the only team that knows the contract exists.

• Data handled
• Privileged or network access
• Service criticality
• Subprocessors and concentration

Review claims with relevant evidence

Request architecture, independent assurance, recovery evidence, incident history and control detail appropriate to the service. Map provider responsibilities against customer responsibilities.

A certificate supports assurance but does not answer every design question.

• Security ownership model
• Identity and encryption design
• Logging and incident notification
• Business continuity and exit

Operate access and change

Use named, time-bound supplier access with strong authentication and logging. Monitor material service, subprocessor and control changes.

Include providers in incident exercises when their service or access is critical.

• Approved support identities
• Access recertification
• Change notification
• Joint escalation contacts

Plan the exit before it is urgent

Document data export, alternative service, access revocation, key rotation and deletion evidence. Test portability for critical providers.

An exit plan also supports incident containment when a connection must be disabled quickly.

• Data and configuration export
• Credential and trust removal
• Verified deletion
• Continuity during transition

A practical 30-day field plan

Week one — Classify. Service, data, access, concentration and impact. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Select. Evidence, architecture and contract. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Operate. Access, change, monitoring and incident coordination. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Exit. Migration, revocation, deletion and evidence. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Data handled — owner, current state, last validation and any open exception
• Security ownership model — owner, current state, last validation and any open exception
• Approved support identities — owner, current state, last validation and any open exception
• Data and configuration export — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the supply-chain security outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?