Information Security Program · Lesson 9 of 13
Design controls across services and suppliers
21 minutes · Content checked 2026-10-17
AI editorial review completed — introductory draft; detailed revised-exam mapping unverified. Target edition: exams from 3 November 2026. Detailed revised-syllabus alignment remains pending.
Read the coverage and AI editorial review report
Loading progress…
Completion records your selection; it does not certify understanding or exam readiness.
What you will learn
- Select safeguards for stated requirements.
- Consider preventive, detective, and recovery capabilities.
- Define supplier responsibilities and evidence.
Design for a requirement
Select a control because it addresses a requirement or risk scenario. Describe the intended result, the owner, how it will operate, and how effectiveness will be assessed. Control catalogs offer useful options; choosing every item without considering context can consume resources without improving the most important outcomes.
Combine capabilities where needed. Access restrictions may reduce unauthorized activity, monitoring may identify misuse, and recovery arrangements may limit disruption. Check interactions: a safeguard that blocks legitimate recovery personnel during an outage may undermine the broader design.
Evaluate architecture boundaries
Map data movement, trust boundaries, administrative access, and shared services. Identify where requirements must be enforced and what happens when a dependency fails. Security architecture should support business services and be reviewed when those services change.
For a supplier-hosted application, clarify which party configures access, monitors events, investigates issues, restores service, and retains records. Shared responsibility needs explicit allocation. A statement that the service is secure is too broad to establish who must perform each task.
Manage the supplier lifecycle
Assess suppliers before engagement, agree requirements, and verify operation throughout the relationship. Consider subcontractors, material service changes, incident communication, recovery capability, and exit arrangements. The depth of review should reflect the service's importance and exposure.
Review evidence for scope and date. A report about one service or period may not cover the system you are buying. Track exceptions and corrective actions. On exit, address access removal, data return or disposal, and continuity of dependent business activities.
Build security into change and supplier acceptance
Define security requirements early enough to influence design and procurement. Before a new service goes live, agree evidence for access control, logging, data handling, recovery, and the responsibilities that matter to its scope. Test the relevant requirements with service owners; a successful data transfer alone is not a complete security acceptance decision.
Record supplier duties in the agreement: incident communication, permitted information use, access, material changes, evidence, subcontractor responsibilities, and exit arrangements where relevant. Monitor adherence using suitable service evidence and follow up exceptions. Neither a contract signature nor a favorable assurance label proves continued compliance.
Work through a scenario
A supplier provides a favorable assurance report for a different product. Is that enough to approve a critical hosted service?
Compare your reasoning
No. Check whether the evidence covers the proposed service, relevant controls, period, and responsibilities; obtain additional evidence for important gaps.
An assurance document is only useful within its scope. Brand reputation cannot substitute for evidence about the actual dependency.
Worked exercise: Review supplier evidence before accepting a change
Fictional facts for learning. These assumptions and thresholds apply only to this exercise. Try the tasks before opening the worked solution.
- Proposed service
- Hosted customer-support platform with an external administrator.
- Evidence supplied
- Assurance report covers a different product and a period ending eighteen months ago.
- Change plan
- Migration test succeeded; access removal, recovery, and security logging were not tested.
Your task
- Identify evidence gaps.
- Define proportionate acceptance criteria and an escalation.
Show worked solution
- The report does not establish assurance for the proposed service and current period. Request evidence covering the actual product, relevant controls, exceptions, customer responsibilities, and material changes since the report.
- Agree testable acceptance criteria: required permissions, revocation, relevant logging and response ownership, data migration integrity, recovery, rollback, and supplier incident contacts. Choose tests with service owners and appropriate authorization.
- Do not accept the change solely because data migrated. Present unresolved gaps and business consequences to the authorized decision maker. Record any approved exception with safeguards, actions, and expiry rather than treating the supplier claim as acceptance.
This exercise is not scored and does not contribute to an exam-readiness result.
Applied study · Added 2026-10-22
Assess a control across supplier boundaries
Continue beyond the introduction. Work through the evidence before opening the model answer.
See it · Try it · Recall it
Picture the topic
Remember this: Direction becomes useful when someone can perform it.
Explore the anchors
State intent and accountability.
Concept matching activity
Match this task or description to its concept:
Define mandatory requirements.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
Visual recap for topic 3A4. Open its full syllabus chapter.
Distinguish control design from operating evidence
Design asks whether the control could address the stated objective. Implementation asks whether it exists in the relevant environment. Operating effectiveness asks whether it performs as required over the stated period. A supplier report may support assurance, but examine scope, dates, exceptions, subservice dependencies and required customer controls. A report about a different product or expired period does not establish the current service’s effectiveness.
Keep accountability visible across the supply chain
Contracts should define data handling, identity administration, logging, incident communication, recovery, subcontracting and exit arrangements where relevant. Assign customer responsibilities instead of treating the supplier’s certificate as complete assurance. When using AI-assisted services, examine permitted data use, retention, model access and change control. Plan an exit that can actually retrieve needed data and revoke access; a contractual right without a workable procedure may fail during disruption.
Evidence case
Fictional facts for learning; no real organization or person is described.
- A supplier assurance report covers its infrastructure service, but the organization uses a separate managed application.
- The report also identifies customer-side access reviews as a required control.
Your task
- Identify two reasons the report is insufficient alone.
- Specify follow-up evidence.
Compare with the model answer
The product scope does not match, and the customer-side review still requires evidence. Obtain assurance relevant to the managed application, review exceptions and dependencies, and verify the customer’s access review. Document limitations rather than presenting the supplier report as an unconditional pass.
This case has two original scenario questions in the expanded practice bank. Practice this course · Edition, coverage and remaining study
Key terms
- Control objective
- The intended result a safeguard should achieve.
- Shared responsibility
- An explicit allocation of operational and security duties between parties.
Remember
- Start with requirements.
- Check dependencies and failure behavior.
- Verify supplier evidence throughout the relationship.
Check your understanding
Why plan an exit before signing a service agreement?
Show explanation
The organization needs a workable path to recover its information, remove access, and maintain critical operations.
Further reading
Examples and explanations are original learning material. These links provide background guidance; they do not certify exam coverage.
Found something unclear or inaccurate? Report a content correction.