Context of the organization
4.3.1
General
Set the limits of the BCMS and where it applies, drawing on the context issues, what interested parties require, and the organization's own mission and goals and its obligations inside and outside the organization; keep the resulting scope as documented information.
What the baseline asks
Set the limits of the BCMS and where it applies, drawing on the context issues, what interested parties require, and the organization's own mission and goals and its obligations inside and outside the organization; keep the resulting scope as documented information.
What it means when the service runs in the cloud
Cloud scope has two dimensions that on-premises scope does not: the service and the deployment. Two customers of the same provider can be in completely different positions because one bought a single region and the other bought a resilient pair.
Evidence an auditor or a customer asks for
- Scope document referencing the context issues and party requirements it was derived from
- Evidence of management approval of the scope
- Version history showing the scope has been maintained
Common gaps in a cloud estate
- Scope asserted without any traceable derivation from context or obligations
- Mission and external obligations ignored, so scope is drawn on organizational convenience
- Scope never re-derived after the context analysis changed
Done well, what the file shows
Done well, this clause leaves a scope document referencing the context issues and party requirements it was derived from that names the service, the region and the date it was last tested, so a reviewer can follow it to the provider document without asking anyone. Where that record does not exist, the gap is visible in the next review whether or not the service is working.
A test you can run this month
State the services and deployment models in scope, not only the provider name.