Overview: Building and Governing Services
Clauses 8.4 and 8.5 address two distinct but fundamentally related concerns. Clause 8.5 addresses the lifecycle process for bringing new or changed services into operation—from design through build, test, and transition. Clause 8.4 addresses the governance of the broader supply chain of external parties contributing to service delivery. Together, they establish the framework for safe, controlled service introduction and the governance of all external dependencies.
Clause 8.4: Supply Chain Management
The Distinction Between Clauses 8.3.2 and 8.4
A frequent source of confusion is the difference between Clause 8.3.2 (supplier relationship management) and Clause 8.4 (supply chain management). Both involve external parties, but they address different scopes:
• Clause 8.3.2 (Relationship Management): focuses on direct relationships with suppliers providing services or components directly to the organization • Clause 8.4 (Supply Chain Management): addresses the broader chain of external parties, including sub-suppliers and the multi-tier network through which services flow
An example clarifies the distinction. The organization contracts with a managed service provider (MSP) for cloud infrastructure support (Clause 8.3.2). The MSP, in turn, relies on a hyperscale cloud provider (AWS, Azure, GCP) for underlying infrastructure. The relationship between the organization and the MSP is Clause 8.3.2 supplier relationship management. The relationship between the MSP and the cloud provider, and the overall governance of the multi-tier chain, is Clause 8.4 supply chain management.
Supply Chain Governance Requirements
Clause 8.4 requires that the organization:
• Determine what is obtained from external parties (services, components, infrastructure, data) • Assess the adequacy of externally provided processes, products, and services to meet SMS requirements • Establish control mechanisms to ensure external parties provide what is required • Communicate requirements to external parties (requirements flow-down) • Define how the organization will verify that external provision meets requirements
In practice, this means mapping your supply chain (understanding all external dependencies), assessing which dependencies are critical or high-risk, and establishing control mechanisms for those dependencies.
Supplier Qualification and Assessment
Before engaging external parties to provide services or components essential to the SMS, the organization should perform supplier qualification or due diligence. This assessment should address:
• Capability: does the supplier have the technical and operational capability to deliver? • Reliability: what is the supplier's track record? Are there references or performance history? • Financial stability: is the supplier financially viable, or is there a risk of insolvency or service cessation? • Information security: what security practices does the supplier employ? Are they compatible with your requirements? • Regulatory compliance: does the supplier meet relevant regulatory requirements (data protection, industry standards)? • Exit readiness: if the relationship were to end, could the supplier support transition?
Requirements Flow-Down
When the organization receives requirements from customers (such as GDPR compliance, specific availability targets, data residency requirements) or is subject to regulatory requirements (such as banking sector resilience standards), these requirements must flow down appropriately to suppliers. A customer requirement for data to remain within a specific geographic region means the organization must ensure that suppliers (and their sub-suppliers) honor this requirement. A regulatory requirement for security incident notification means suppliers must be contractually obligated to notify the organization of security incidents within specified timeframes.
Requirements flow-down is often overlooked. Organizations may have stringent data protection requirements but fail to communicate these to their suppliers. Or they may assume suppliers understand requirements without explicitly documenting them. Clause 8.4 requires explicit communication and agreement.
Multi-Tier Supply Chain Visibility and Risk
Modern services often depend on multiple tiers of suppliers. Your cloud infrastructure provider may rely on hardware manufacturers. Your managed security service provider may rely on a threat intelligence vendor. This creates supply chain complexity and risk:
• Concentration risk: multiple critical services may rely on a single sub-supplier, creating a single point of failure • Geographic risk: sub-suppliers may be concentrated in regions subject to political, natural disaster, or regulatory risk • Vendor lock-in: changing one component may be costly or infeasible due to dependencies created by the supply chain structure • Cascade failure: if a sub-supplier fails, multiple first-tier suppliers and ultimately your services may be affected
Clause 8.4 requires the organization to map and understand its supply chain. This is not an academic exercise—organizations should be able to identify which services depend on which sub-suppliers and understand the risks this creates.
Supply Chain Incident Response
What happens when a supplier in your supply chain fails—they go out of business, they experience a major security breach, they are subject to cyberattack, or they cease supporting your region? Clause 8.4 implies that the organization must have plans to address supply chain incidents. This includes:
• Supplier failure impact assessment: which of your services would be affected if this supplier failed? • Escalation procedures: how does the organization learn about supplier issues quickly enough to respond? • Incident response: what are the steps to maintain service if the supplier cannot? • Contingency activation: can the organization shift to a backup supplier or alternate arrangement quickly? • Communication: how do you notify customers when a supply chain incident affects them?
Indonesian Regulatory Context: Third-Party Risk Management
For financial sector organizations operating in Indonesia, supply chain management intersects with OJK (Otoritas Jasa Keuangan) regulatory requirements. POJK 11/2022 and related guidance emphasize third-party risk management, particularly for IT service providers and critical technology vendors. The regulatory expectation includes:
• Documented assessment of third-party risk before engagement • Ongoing monitoring of third-party performance and risk • Requirements for security, operational continuity, and data protection • Periodic audits or assessments of critical third parties • Contingency planning for critical third-party failure • Escalation to senior management when third-party risks materialize
Clause 8.4 supply chain management aligns closely with these OJK expectations.
| KEY CONCEPT | Supply chain management requires understanding not just your direct suppliers, but the full chain of external parties on which service delivery depends. A failure anywhere in the chain can cascade to affect your customers. |
Clause 8.5: Service Design, Build, and Transition
Scope and Purpose
Clause 8.5 addresses the process of introducing new services or significantly changing existing services. It encompasses the full lifecycle from concept through design, build, test, transition into production, and post-transition review. The requirement is that this process must be planned and controlled—new services must not appear in production ad hoc without formal design, build, test, and transition processes.
Service Design
Service design begins with capturing customer requirements for the new or changed service. This includes:
• Business requirements: what business outcome or customer need does the service address? • Functional requirements: what specific capabilities must the service provide? • Performance requirements: what availability, response time, capacity targets must be achieved? • Security and compliance requirements: what data protection and regulatory requirements apply? • Continuity requirements: what recovery objectives does the service need to support? • Integration requirements: how must the service integrate with existing systems and processes?
Based on these requirements, the design phase produces:
• Service architecture: the high-level design of how the service will be structured • Component design: the specific technology components, infrastructure, and processes that make up the service • Service level targets: the SLA targets the service is designed to meet • Configuration: how the service components are configured • Documentation: design documents, architecture diagrams, and technical specifications
Design requirements must be incorporated into the organization's service management plan—integrating the new service into the SMS scope and identifying any necessary adjustments to service management practices.
Build and Test
Once the design is approved, the service components are built, procured, or configured. This is followed by testing to verify that the service meets its design requirements:
• Functional testing: does the service provide the required capabilities? • Performance testing: does the service meet performance targets (response time, throughput, availability)? • Security testing: are security controls effective? Can the service resist or detect attacks? • Integration testing: does the service integrate correctly with existing systems? • Load and stress testing: how does the service perform under heavy load or stress conditions? • User acceptance testing: do users/customers accept that the service meets their needs?
Testing must be documented. Test plans must be established (what will be tested, what are the pass/fail criteria), test cases must be executed, and test results must be recorded. Test completion and sign-off by appropriate stakeholders must be documented before transition proceeds.
Transition Planning and Execution
Transition is the process of moving the new or changed service from the test/development environment into production where customers will use it. Transition is high-risk because it involves changes to the live production environment. ISO 20000 requires that transitions be planned in detail.
A transition plan must address:
• Transition timeline: the detailed schedule of transition activities (go-live date, cutover windows, rollback windows) • Implementation activities: step-by-step what will be done to move the service into production • Roles and responsibilities: who is responsible for each transition activity • Communication plan: how stakeholders (customers, support staff, leadership) will be kept informed • Training plan: how staff will be trained before the service goes live • Acceptance criteria: what must be verified before the transition is considered successful • Rollback plan: if something goes wrong, how will the organization revert to the prior state • Risk assessment: what risks might occur during transition, and how will they be mitigated • Testing in production: what testing will occur after the service goes live (smoke testing, health checks)
The transition plan must be approved by appropriate stakeholders (service owner, change management, operations) before transition begins. This is typically documented as a change request that goes through the Clause 8.6.5 change management process.
Post-Transition Review and Service Portfolio Addition
After transition, the organization should conduct a post-transition review. This review verifies that:
• The service is operating in production and serving customers • The service meets its design requirements and acceptance criteria • The service is performing within SLA targets • No critical issues from the transition remain unresolved • Customers are satisfied with the transitioned service
Once the service has been in production for a suitable period (typically several days to weeks, depending on criticality) and post-transition review is positive, the service is formally added to the service portfolio with full metadata (portfolio entry per Clause 8.2).
Relationship to Change Management (Clause 8.6.5)
Major service transitions typically require changes to the production environment that must go through the change management process (Clause 8.6.5). The transition plan (from Clause 8.5) becomes the basis for the change request (from Clause 8.6.5). These two practices must be integrated: Clause 8.5 defines how services are designed and transitioned; Clause 8.6.5 defines how changes in general are controlled. A transition is a type of change, and it must meet both sets of requirements.
Common Clause 8.5 Audit Findings
• New services implemented without formal transition planning; services appear in production without formal transition records • No documented design requirements or design sign-off before build begins • Test plans and test results not documented; testing occurs informally without recorded evidence • No documented acceptance criteria or post-transition review; new services not formally accepted into the portfolio • New services not included in the service portfolio or only added months after going live • Transition plan exists but is not aligned with change management process; transition and change are not integrated • No documented evidence that customers accepted the transitioned service
| IMPORTANT | A new service deployed to production without formal transition planning and control is not under SMS control until the transition process is completed. Until then, the service sits outside the SMS boundary, even if it is actively serving customers. |
| BITLION INSIGHT | Bitlion GRC service design and transition management templates provide structured frameworks for new service introduction, ensuring alignment between design requirements, test planning, transition execution, and formal portfolio entry. |
Service Transition Checklist
| Phase | Activity | Responsible | Sign-off Required | Evidence |
|---|---|---|---|---|
| Design | Capture design requirements from customer and regulatory needs | Service Owner | Service Owner, Customer | Requirements document, sign-off sheet |
| Design | Approve service architecture and design | Technical Lead | Change Advisory Board | Architecture diagram, design approval |
| Build | Build and configure service components | Infrastructure/Dev Team | Technical Lead | Configuration records, build checklist |
| Test | Execute functional, performance, and security testing | QA Team | QA Lead | Test plan, test results, sign-off |
| Transition | Develop detailed transition plan with rollback | Change Manager | Change Advisory Board | Transition plan document, approval |
| Transition | Execute transition activities per plan | Operations Team | Operations Lead | Transition log, activity records |
| Transition | Verify service is operational and meets acceptance criteria | Service Owner | Service Owner, Customer | Acceptance sign-off |
| Post-Transition | Conduct post-transition review and close any issues | Service Owner | Service Owner | Post-transition review report |
| Portfolio | Add service to portfolio with full metadata | Portfolio Manager | Service Owner | Portfolio entry, SLA documentation |