BigSavantLEARN. PRACTICE. GROW.
← CISM: manage security, risk, and incidents
24 / 25 · 220 MIN

Assets, shared controls and lifecycle

Follow data and decisions across systems, allocate control duties and reconcile evidence with the current service boundary.

Inventory information through flows

Start with the business service and follow input, transformation, storage, export and consumption. A server inventory does not describe every information copy. Include replicas, reports, diagnostic files, metadata and test data when within defined scope. For each asset, record stable identity, purpose, owner, location and permitted users. Maintain links between sources and derivatives. A daily scanner may never observe exports lasting twenty minutes; creation events and pipeline definitions help reconcile that lifecycle. Discovery tools and responsible people provide complementary perspectives.

Classification by meaning, impact and linkage

The absence of balances does not make a file linking customers to funds public. Classification considers meaning, consequences and applicable handling requirements. Combining public data with internal timings may reveal an undisclosed strategy. The owner validates meaning with security and privacy support. In test data, replacing names with codes does not guarantee anonymity when a lookup table or linkable attributes remain. Document transformation and analysis before reducing protection. A folder called temporary or test describes use; it does not automatically determine content classification.

Stable identity and unknown state

Two names may refer to the same asset. Reconcile them through verified identifiers and relationships while retaining useful historical aliases. The reverse also occurs: the same name starts referring to another tenant or dataset. Record identity or boundary changes. When classification is missing, do not remove the asset from reporting; expose the unknown and assign action. In the SQL exercise, the asset table anchors the query and relationships use LEFT JOIN. A deleted tag or missing responsibility therefore remains visible. This technical choice implements a management requirement: missing metadata must not erase an obligation.

Decompose shared responsibilities

Shared is not an executable instruction. For key management, separate creation, protection, authorization, rotation, recovery and verification; identify who performs each task and which dependency comes from the other party. A provider physical control may be inherited while application permissions remain customer-configured. The actual model depends on the contracted service and its use. Review those divisions during migration instead of copying the old matrix. The local exercise flags unsupported inheritance when physical-protection evidence is used to justify data-access authorization.

Integrate authorization across effect-producing paths

A rule applied to the human interface may be bypassed through batches, APIs or emergency automation. Map paths producing the same effect and identify where each checks authorization. Consider time as well: cached decisions can outlive central revocation, and aliases can change between approval and execution. Integration should verify the effective target and state at the time required by the objective. For technical identities, connect creation and deactivation to the service lifecycle. Employee offboarding does not automatically cover credentials created through deployment.

Accept changes without inheriting outdated assumptions

A tenant, connector or configuration change can alter a control without changing code. Maintain a scope version identifying the context in which implementation and evidence were assessed. When that context changes, determine which parts need renewed confirmation; do not automatically invalidate everything or carry results forward solely because names resemble each other. For rollback, check whether previous state reintroduces removed permissions. For file transformations, storage integrity does not demonstrate that local processing preserved the business property. Select input, transformation and output criteria matching actual responsibilities.

Prepare people for new tasks and conditions

General training does not necessarily prepare someone to recover a key or manage temporary delegation. Identify the task, authority, success criteria and failure conditions. Use supervised practice and a case different from the worked example to assess application. The environment must support the assessed version and requirement: failing someone for not executing a nonexistent function measures the environment, not competence. Also examine incentives and decision paths. If service handling requires identity verification but rewards only speed and provides no escalation, the process pressures people to bypass their training. Assessment equivalence requires distinguishing skill from an access barrier. In training that assesses classification decisions, colors without textual alternatives and unlabeled buttons can prevent a screen reader from presenting the situation. More time does not supply information that remains inaccessible. Publish a version with identifiable categories and actions while preserving cases, decisions and criteria; do not ask a colleague to choose for the learner or replace application with terminology recall. Confirm with the learner that the interface is usable before interpreting performance. The conclusion concerns the assessed task; inability cannot be inferred from a barrier introduced by the exercise itself.

Lab: find four gaps through joins

From the project root, run python3 content/labs/cism-program-controls/run.py --output /tmp/cism-program-first.json using a new output filename. The SQLite database is temporary and contains five fictional assets and six obligations. The initial result should show four gaps: export lacks classification and an access owner; worker has unsupported inheritance; report has version-2 evidence for a version-3 service. Ledger and public-page provide valid cases. Read the rows and explain each gap before consulting automatic checks. The script also checks duplicates, invalid references and missing evidence, implementation or requirements.

Change exercise: repair a decision without hiding the asset

Copy content/labs/cism-program-controls/fixture.json to a working file. Classify export as restricted, assign its duty to customer, set worker’s control to local with scope access and change report’s evidence to version 3. These edits represent fictional decisions already justified in the exercise; editing a number would not constitute production evidence. Run --fixture against the copy with a new --output and compare issues. Then remove only ledger’s classification. The asset should remain visible with two obligations and a classification alert. Explain why filtering only tagged assets would produce misleading reporting. Changing only mode to local while retaining physical scope does not repair the access obligation; local-scope-mismatch remains. A null result is not a pass either: evidence-result-missing keeps the missing conclusion visible even at the current version.

Final case and program-management summary

Before accepting a migration, combine flows, classification, shared tasks and applicable evidence. A partner may demonstrate physical protection while the organization still lacks authorization configuration in the new tenant. A derived file may remain outside inventory and earlier evidence may not cover the current boundary. Present gaps by service, impact, owner, action and requested decision. Avoid a single green status combining planned, inherited and tested controls. The lab demonstrates local queries and rules; it does not discover real assets, inspect providers, authorize releases or prove compliance. Connect the work with asset management, IAM, change, assurance and program communication. If A depends on C, local A tests do not remove an unproven condition in C; an independent service B may have a separate phased decision.

Effective dates, purpose and inference

Inventory should represent state at the decision date. A retirement request approved on day two with deactivation on day seven does not remove the asset from a day-five assessment. A documented day-four activation enters that assessment even if formal inventory still dates from day one. Retain record and effective dates; they answer different questions. During APS handover, reconcile the population with executed and planned changes without confusing future authorization with a completed event. A copy’s content also merits its own assessment. Under a fictional policy, identifiable complaints serve case resolution; service improvement receives only statistics without identifiers or free text; marketing is not authorized. Encrypting a copy or retaining classification does not extend its purpose. Conversely, removing names does not ensure that disclosure ceases to reveal individual information. Publishing five clients’ total as 100 and a known subtotal for the other four as 70 lets recipients calculate 30 for the fifth. Disclosure review should consider the accessible set, including earlier releases; delaying the second table or rounding integers to whole units does not undo inference. Pitfall: assessing each file in isolation or treating technical access as authorization for every use. Takeaway: population, purpose and inferable information must be assessed in actual context. Connect inventory to classification, change management and data flows.

Migrate identities without expanding authority

An identifier is unique only within its issuing namespace unless a different guarantee is explicit. In a fictional model, Ana is (R1,42) before migration; at the destination Bruno is (R2,42) and Ana is (R2,77). Comparing 42 alone joins different people. Use the authoritative association between identity pairs rather than infer equivalence from matching numbers or an attribute without a uniqueness guarantee. Record the association’s origin and handle unresolved entries under the approved procedure. Correct association still does not define destination authority. If Ana held A and B but the new authorization permits only A, copying old rights preserves excess access. Tests need positive and negative outcomes directed at both dimensions: Ana can use A; Ana cannot use B; Bruno does not receive A through the numeric collision. Denying every identity avoids excess grants but does not satisfy a migration whose criteria include continuity of Ana’s authorized access. This model does not describe an identity provider’s automatic behavior; issuers, mappings and mandates are explicit exercise data. Pitfall: correcting only the identity key or only the permission list and declaring integration complete. Takeaway: preserve the correct person and apply correct destination authorization. Connect migration with directories, trust boundaries, access management and integration regression.

Separate observed failure from an unassessable task

A training result should be linked to the task and conditions under which it was observed. In an assessment with independent A and B tasks, the environment supports A: Ana makes the required decision correctly while Bruno gets it wrong. B requires a feature absent from the installed version. These are three distinct states: Ana demonstrates A capability; Bruno has an observed A error; B execution is unassessed for both. One “everyone failed” label loses that information. Before prescribing training, locate where every observation arose. Repeating B in the same incompatible environment does not measure the missing competence. Correct the environment and exercise B; for Bruno, also address the A decision with observed error. Do not convert recognition of the environment defect into a B pass: absence of assessment opportunity is not success. Nor should valid A results automatically be invalidated when the prompt confirms task independence. If policy permits per-task authorization, management can limit authorization to the actually demonstrated scope; if it requires the full set, that different rule must be respected. Pitfall: using an environment problem to pass everything or discard all evidence. Takeaway: preserve granularity distinguishing ability, error and missing observation. Connect assessment with role design, permissions, handover and training-environment version management.

Report validity at the same instant

“Last success” and “evidence valid now” answer different questions. A report with a reference time should apply that time to every element of its criterion. In a teaching model, each service needs local and supplier evidence simultaneously valid. Windows include start and exclude end. Two historically successful tests do not guarantee that their windows overlap at the reporting instant. At 12:00, a service with local validity 10:00–13:00 and supplier validity 11:00–14:00 satisfies both. Another with supplier validity 12:00–16:00 already qualifies at that instant if its local window also covers it. Evidence ending at 12:00 no longer counts under the declared convention; supplier evidence ending at 11:00 is not renewed by a later local test either. Show reference time, both windows and resulting state per service. Keep history separately to explain change without converting it into current authorization. The conclusion is limited to the exercise criterion; it does not prove readiness in every other operational respect. Pitfall: combining each team’s last success without checking simultaneous validity or treating the starting boundary as exclusive. Takeaway: temporal conclusions need a common instant and explicit boundary rules. Connect reporting with evidence validity, renewal, acceptance gates and observability.

python3 content/labs/cism-program-controls/run.py --output /tmp/cism-program-first.json
python3 content/labs/cism-program-controls/run.py --fixture /tmp/cism-program-working.json --output /tmp/cism-program-changed.json
IN PRACTICE

A migration creates an unclassified report export and tries to inherit access control from physical-protection evidence. The obligation register keeps both gaps visible until applicable decisions and evidence exist.

Common pitfalls

Confusing names with identities; treating test data as public; using a shared label without tasks; inheriting evidence from another layer; dropping unknowns through an INNER JOIN; editing versions as though that were a new test.

Related topics: Inventory and classification · Shared responsibility · IAM integration · Change and rollback · Supplier assurance

Take this idea with you

Follow the asset, define the obligation, assign the task and check evidence at the current boundary. Keep unknowns visible and distinguish the local model from actual execution.

Create account
PreviousNext lesson

References

CISM® is a registered trademark of ISACA. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by ISACA. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.