Changed-Fact Decision Key — Scenarios 01–09
Use only after attempting the original scenario.
S1 — Correct login, wrong data
Primary: Authorization/Entitlement exceeds need after successful Authentication.
Best: least-privilege role/entitlement + traceable approval.
Weaker: stronger password.
Changed fact: identity cannot be proven because credentials are weak/stolen → Authentication becomes primary.
Supporting KAs / roles: Data Governance, Metadata; Data Owner, Steward, IAM/security, application owner.
S2 — Production data copied to Test
Primary: sensitive-data proliferation into weak non-production.
Best: avoid Production data or use Persistent, preferably In-flight, masking while preserving needed relationships.
Weaker: “Test is internal.”
Changed fact: true stored value must remain but users should see protected representation → Dynamic masking.
Supporting: Governance, Storage & Operations; Owner/Steward, security/privacy, DBA/test.
S3 — Call-center verification
Primary: partial visibility while Production truth remains.
Best: Dynamic masking.
Weaker: persistently overwrite Production.
Changed fact: a Test database itself must contain permanently altered values → Persistent masking.
Supporting: Governance; Owner, app owner, IAM/security, supervisor.
S4 — Bulk patient export
Primary: legitimate-privilege abuse.
Best: contextual/query/endpoint controls + monitoring/evidence.
Weaker: classify automatically as Excessive privilege.
Changed fact: the role should never have allowed population access → Excessive privilege.
Supporting: Governance, Metadata; Owner, security monitoring, business owner, auditor.
S5 — Developer becomes DBA
Primary: privilege elevation through vulnerability.
Best: remediate vulnerable path + prevention/detection + least privilege.
Weaker: only rewrite role grants.
Changed fact: developer was intentionally granted DBA despite no need → Excessive privilege.
Supporting: Storage & Operations, Governance; DBA, developer, security operations, risk/control owner.
S6 — Generic support login
Primary: shared-account abuse / loss of attribution.
Best: unique identities, role membership, auditable activity.
Weaker: keep shared ID with manual notes.
Changed fact: non-human process ID tightly restricted to one task → Service account.
Supporting: Governance; IAM/security, support manager, Owner, auditor.
S7 — Batch account reuse
Primary: service-account credentials used outside purpose.
Best: restrict commands/systems, protect credentials, no human ad-hoc reuse.
Changed fact: several humans intentionally use one generic interactive login → Shared account abuse.
Supporting: Storage & Operations, Governance; service owner, IAM/security, DBA, process owner.
S8 — Confidential plus regulated
Primary: restriction aggregation.
Best: one highest confidentiality level + all applicable external categories/actions.
Weaker: keep only the “highest” regulation.
Changed fact: no external categories apply; only internal need-to-know → Confidentiality alone.
Supporting: Governance, Metadata; Steward/Owner, legal/compliance, security.
S9 — Strong-password policy
Primary: policy intent lacks measurable Standard.
Best: define enforceable Standard + controls/evidence.
Weaker: restate policy more strongly.
Changed fact: detailed rule exists but systems do not enforce it → missing Control/Procedure.
Supporting: Governance; policy owner, IAM/platform admins, audit/compliance.