LEARN. PRACTICE. GROW.Turn a requirement into verifiable scope
Start with a statement the team can demonstrate. “The platform is compliant” does not identify resources, data, operations, period or criteria. In this lesson's fictional project, the internal requirement includes primary and recovery environments. The acceptance package needs to show both. An average of positive results can hide that recovery was never reviewed. These examples do not describe internal BNP Paribas procedures or establish a particular legal obligation. Build a matrix with one row for each resource and applicable control. Record requirement, owner, implementation, evidence and limitations. If a control does not apply, document why and who approved that classification. Do not use an empty field to mean unknown, waived and verified simultaneously. Those states lead to different actions and need to remain distinguishable in the committee report, including when progress is summarized for managers who will not inspect every technical record. Include scope changes. A new backup destination, additional service or support path might require updating the matrix. Earlier evidence remains useful within its scope but does not automatically cover the new component. Before deciding, ask the service owner to confirm inventory and control owners to explain gaps. The PM coordinates that review and retains traceable decisions; choosing a suitably named product does not replace specialist interpretation of requirements or evidence that the intended controls actually operate.
Verify location by resource and service
Read a location restriction with its technical scope. resource locations limits creation of supported resources in allowed locations. It does not automatically move old resources into the selected region. If inventory includes a resource predating the policy, the team needs to examine that resource separately. A test showing rejection of a new out-of-region creation is useful, but answers only that tested operation. Preserve this boundary in acceptance evidence rather than stretching one successful check across the inventory. Do not turn creation location into a universal promise about data storage and processing. Global resources, types without location selection and service-specific behavior exist. Prepare a row per component with relevant configuration and applicable documentation. For the fictional reconciliation service, include primary, recovery, exported copies and observability where they fall within approved scope. Avoid inferring data location from one VM's region or from a project naming convention. The change plan should preserve continuity. A new restriction can prevent creation operations that a routine depends on without immediately affecting existing resources. Identify those routines and rehearse the change within controlled scope. If data migration is needed, manage it as separate work with an owner, validation and contingency. In the committee presentation, distinguish the control already preventing new creation from work still needed on older inventory and service-specific checks. This makes both delivery dependencies and the limits of the current assurance visible.
Relate package, service and installed version
Assured Workloads organizes controls into packages with specific scopes. Before adding a service to a folder, confirm support in the chosen package. Finding the service in another package does not establish coverage in the current one. The architecture decision should state functional need, required control and documented correspondence. If correspondence is missing, the team needs to revisit design or scope decisions rather than merely edit the report wording or rely on the provider's general product catalogue. Configuration also has an effective version. An available update does not mean it has already been evaluated and applied to the folder. Keep current state, proposal and adoption decision separate. In the fictional example, the project team wants to cite the new version before completing impact analysis. The PM should request confirmation of installed state and assign change review, including dependencies that the proposed values might affect. A notification is an input to that process, not evidence of its completion. Prepare a short decision note: current configuration, proposed change, reason, impact, rehearsal and owner. If adoption is deferred, explain the decision and necessary follow-up without declaring the new configuration active. After application, collect evidence of the result in the correct scope. Current documentation helps planning, but acceptance also depends on what is actually configured in the workload handed over to operations. Retain that distinction when reporting progress across several folders or projects.
Handle exceptions without counting them as fixes
An approved exception and a remediated control are different outcomes. In Assured Workloads, Exception records a decision with justification; Resolved represents remediation of the violation. Keep technical state and risk decision visible. In the fictional scenario, one primary-environment control has a temporary exception. That decision does not fill missing recovery-environment evidence or prove that underlying configuration changed. An aggregate report should preserve those distinctions rather than convert every approved item into a technical pass. Define exception scope, owner, conditions, follow-up and review point under the internal process. Ambiguous approval can be interpreted as permanent permission by a team receiving only the ticket months later. Record what was accepted and what remains to be done. If architecture changes, reassess applicability instead of automatically carrying the decision to new resources or a different purpose. Any acceptance should remain connected to the decision that actually occurred. Operational response also needs coverage. Assured Workloads Monitoring emails do not cover resource violations. A process waiting only for those messages leaves a category without suitable observation. Confirm available mechanisms and assign their operation. At the committee, communicate gaps and exceptions separately, with actions and owners. Avoid turning absent notifications, absent questions or administrative approval into a technical conclusion that every requirement was satisfied throughout the period. Those are different kinds of evidence with different limits.
Review provider-access scope
A support request needs a description precise enough for informed scope approval. In Access Approval, check resource, purpose, location characteristics and duration. Approving a parent resource also covers its descendants. If the scenario need is limited to one object, do not record bucket approval as though it covered only that object. Ticket wording does not change technical request scope, so a mismatch needs a decision before the assurance is presented as complete. Approval should not be described as exclusive to the employee who initiated it. Approved characteristics can cover other matching personnel within the conditions and timeframe. This does not mean unrestricted access or creation of new IAM roles. The PM should communicate what was actually approved and who in the organization follows the intervention. A precise decision avoids both excessive promises and interpretations that remove the stated access boundaries. When querying pending requests in the console, check the selected resource level. A folder view does not automatically establish that every child project has no requests. Define the monitoring routine at the correct scope with authorized owners. For this exercise, prepare a fictional note with need, requested scope, detected difference and next action. Use no real support data. Then relate access evidence to the decision while preserving documented limitations and exclusions for the involved services. A short window alone does not resolve a mismatch in resource scope.
Interpret records without changing their meaning
Read an audit field according to its definition. In Access Transparency, permanent-office country and the physical country reported for access are different fields. If principalOfficeCountry is PT and principalPhysicalLocationCountry is DE, do not use PT as physical location merely because it appears first. Neither field alone establishes the region where data was stored. The auditor's question determines what evidence is needed and which record can support the answer. In the fictional exercise, the committee asks for three statements: approved scope, recorded access and resource location configuration. Prepare three answers with appropriate references. An approval request does not replace an access record; an access record does not replace resource configuration. Linking documents helps investigation but does not make their meanings interchangeable. Also preserve unknown values rather than filling them with a convenient assumption, especially when a summary hides the original field definitions. In the evidence note, include period, source, resource and observation limits. Avoid copying sensitive payloads when bounded identifiers and authorized references suffice. If two records appear contradictory, check whether they describe the same operation and moment before deciding one is wrong. The PM's task is to coordinate a traceable explanation that technical and control teams can review without turning every available field into a broader guarantee than it supports. State the next collection needed where the current record cannot answer the actual question.
Assign responsibilities that work during incidents
Shared responsibility needs concrete tasks. For each control, identify who configures it, operates it, observes failures and decides changes. Distribution varies with service and workload; a generic matrix can guide questions but does not replace the operating agreement. In the fictional case, an internal commitment requires a business update within 15 minutes. Provider response targets differ. Waiting for support does not remove the need to communicate facts, impact and the next update, even while root cause remains uncertain. Prepare handover with actions the production team can execute. Include contacts, access scope, evidence location, escalation criteria and authority for urgent decisions. A name in a table does not demonstrate operational capability. Walk through a synthetic incident: who receives the alert, confirms impact, opens the support request and keeps the business informed? Record dependencies preventing intended autonomy rather than assuming the implementation team will remain available indefinitely. At acceptance, avoid one completed state for different activities. Infrastructure might be delivered while training, access or control observation remains missing. Relate each pending item to consequence, owner and agreed date. If acceptance is phased, bound what actually entered operation. That clarity helps manage time and budget without hiding remaining work and lets the RUN team maintain the service after the project no longer has dedicated implementation staff. The agreed evidence should support that transfer of responsibility as well as technical installation.
Exercise: resource and period coverage
The Python exercise uses a fictional matrix of requirements and interval-based evidence. Each requirement identifies resource, control and owner. Each evidence record declares a result and period with an inclusive start and exclusive end. Two adjacent intervals can cover the full period; separated intervals leave a gap. The program compares these assertions. It does not prove continuous control operation or determine legal compliance, and it never inspects an actual cloud resource. Before running python3 run.py, predict the result with primary evidence only. Recovery should remain unproven. Then split recovery evidence into two touching intervals and observe declared coverage. Introduce a failure inside the period: it remains visible even when a broad positive statement exists. An approved exception is displayed separately and never converted into a pass. A requirement without an owner still prevents the model's complete-coverage conclusion, because ownership is an explicit requirement of this exercise. For coverage, the program ignores evidence outside resource or period scope but lists its identifiers for review. Use results to write the committee note: assessed scope, gaps, failures, exceptions and next action. Do not use allRequirementsCovered as production approval. The lesson summary is to preserve correspondence between requirement, resource, period, owner and evidence. Where correspondence is missing, describe the gap and assign work to resolve it while retaining the difference between an accepted decision and a demonstrated control.
"""Original offline control-evidence coverage worksheet.
Intervals are [start,end). Evidence coverage is a supplied assertion, not proof
that a technical control operated continuously. Exceptions never become passes.
No legal determination, cloud inspection, evidence authentication or production action.
"""
from copy import deepcopy
from hashlib import sha256
from itertools import permutations, product
from math import isfinite
from pathlib import Path
import json
def text(v):
if not isinstance(v, str) or not v.strip:
raise ValueError('expected nonempty string')
return v
def interval(start, end):
for n in (start, end):
if type(n) not in (int, float) or not isfinite(n):
raise ValueError('invalid interval value')
if start >= end:
raise ValueError('empty or reversed interval')
return start, end
def gaps(spans, start, end):
cursor, missing = start, []
for left, right in sorted(spans):
if left > cursor:
missing.append([cursor, left])
cursor = max(cursor, right)
if cursor < end:
missing.append([cursor, end])
return missing
def coverage(requirements, evidence, start=0, end=6):
interval(start, end)
if not isinstance(requirements, list) or not requirements or not isinstance(evidence, list):
raise ValueError('requirements and evidence lists required')
required = {}
for item in requirements:
if not isinstance(item, dict):
raise ValueError('invalid requirement')
key = text(item.get('resource')), text(item.get('control'))
if key in required:
raise ValueError('duplicate requirement')
owner = item.get('owner')
if owner is not None:
text(owner)
required[key] = owner
seen, records, outside_scope = set, {}, []
for item in evidence:
if not isinstance(item, dict):
raise ValueError('invalid evidence')
identifier = text(item.get('id'))
if identifier in seen:
raise ValueError('duplicate evidence ID')
seen.add(identifier)
key = text(item.get('resource')), text(item.get('control'))
left, right = interval(item.get('start'), item.get('end'))
state = item.get('result')
if state not in ('pass', 'fail', 'unknown'):
raise ValueError('invalid result')
exception = item.get('exception')
if exception is not None:
if not isinstance(exception, dict):
raise ValueError('invalid exception')
text(exception.get('id'))
interval(exception.get('start'), exception.get('end'))
if type(exception.get('approved')) is not bool:
raise ValueError('invalid exception approval')
if key not in required or right <= start or left >= end:
outside_scope.append(identifier)
else:
records.setdefault(key, []).append(item)
rows = []
for key, owner in sorted(required.items):
positive, failures, exceptions = [], [], []
for item in records.get(key, []):
span = [max(start, item['start']), min(end, item['end'])]
if item['result'] == 'pass':
positive.append(span)
elif item['result'] == 'fail':
failures.append(dict(id=item['id'], interval=span))
ex = item.get('exception')
if ex and ex['approved'] and ex['start'] <= start and ex['end'] >= end:
exceptions.append(ex['id'])
missing = gaps(positive, start, end)
status = 'failed' if failures else ('unproven' if missing else 'covered-by-supplied-evidence')
rows.append(dict(resource=key[0], control=key[1], owner=owner,
ownershipMissing=owner is None, status=status,
uncoveredIntervals=missing,
failures=sorted(failures, key=lambda x: x['id']),
approvedExceptions=sorted(set(exceptions))))
return dict(rows=rows, outsideScopeEvidence=sorted(outside_scope),
allRequirementsCovered=all(r['status'] == 'covered-by-supplied-evidence' and not r['ownershipMissing'] for r in rows),
actualComplianceProven=False, productionAuthorized=False)
def main:
requirements = [dict(resource='primary', control='access', owner='APS'),
dict(resource='recovery', control='access', owner='APS')]
primary = dict(id='p', resource='primary', control='access', start=0, end=6, result='pass')
recovery = dict(primary, id='r', resource='recovery')
fixtures = []
def case(name, evidence, expected, req=None):
req = requirements if req is None else req
before = deepcopy((req, evidence))
result = coverage(req, evidence)
assert result['allRequirementsCovered'] is expected, name
assert (req, evidence) == before
fixtures.append(dict(id=name, **result))
return result
case('both-environments', [primary, recovery], True)
case('missing-recovery', [primary], False)
case('adjacent-evidence', [primary, dict(recovery, end=3), dict(recovery, id='r2', start=3)], True)
case('period-gap', [primary, dict(recovery, end=2), dict(recovery, id='r2', start=3)], False)
case('overlap', [primary, dict(recovery, end=4), dict(recovery, id='r2', start=3)], True)
case('conflicting-failure', [primary, recovery, dict(recovery, id='r2', result='fail', start=2, end=3)], False)
exception = dict(id='waiver1', start=0, end=6, approved=True)
case('approved-exception-not-pass', [primary, dict(recovery, result='fail', exception=exception)], False)
case('expired-exception', [primary, dict(recovery, result='fail', exception=dict(exception, end=5))], False)
case('unknown-evidence', [primary, dict(recovery, result='unknown')], False)
case('outside-period', [primary, recovery, dict(recovery, id='r2', result='fail', start=6, end=8)], True)
case('outside-resource', [primary, recovery, dict(recovery, id='r2', resource='development', result='fail')], True)
case('missing-owner', [primary, recovery], False, [requirements[0], dict(requirements[1], owner=None)])
combinations = 0
for left_end, right_start in product(range(1, 7), range(0, 6)):
spans = [dict(recovery, end=left_end), dict(recovery, id='r2', start=right_start)]
result = coverage(requirements, [primary, *spans])
covered_ticks = {t for t in range(6) if any(x['start'] <= t < x['end'] for x in spans)}
assert result['allRequirementsCovered'] == (covered_ticks == set(range(6)))
combinations += 1
records = [primary, dict(recovery, end=3), dict(recovery, id='r2', start=3)]
expected = coverage(requirements, records)
permutations_checked = 0
for order in permutations(records):
assert coverage(requirements, list(order)) == expected
permutations_checked += 1
invalid = [
([], [], {}),
([requirements[0], requirements[0]], [], {}),
([dict(requirements[0], owner='')], [], {}),
(requirements, [primary, primary], {}),
(requirements, [dict(primary, result=True)], {}),
(requirements, [dict(primary, start=3, end=3)], {}),
(requirements, [dict(primary, start=True)], {}),
(requirements, [dict(primary, end=float('inf'))], {}),
(requirements, [dict(primary, exception=dict(exception, approved='true'))], {}),
(requirements, [dict(primary, exception=dict(exception, id=''))], {}),
(requirements, [dict(primary, resource='')], {}),
(requirements, [None], {}),
(requirements, [], dict(start=6, end=0)),
(requirements, [], dict(end=float('nan'))),
]
for req, ev, kwargs in invalid:
try:
coverage(req, ev, **kwargs)
except ValueError:
pass
else:
raise AssertionError('invalid input accepted')
print(json.dumps(dict(labId='pcse-control-scope', fixtures=fixtures,
intervalCombinations=combinations, inputPermutations=permutations_checked,
invalidInputs=len(invalid), inputPreserved=True, orderIndependent=True,
network=False, cloudExecuted=False, persistentWrites=False,
scriptSha256=sha256(Path(__file__).read_bytes).hexdigest), indent=2))
if __name__ == '__main__':
main
Primary has evidence, recovery is not yet reviewed and an exception was approved; the committee needs all three states.
Common pitfalls
Treating creation restriction as migration, an available update as installed, an exception as remediation and notification silence as coverage proof.
Related topics: Risk and exception management · Production handover and responsibilities · Access auditing and data location
Claim only scope and periods supported by evidence and keep exceptions and responsibilities visible.
Reference: Shared responsibilities and shared fate on Google Cloud · Current linked guide; edition date unconfirmed (2026-09-30 inspection)