A regional clinic maps ransomware exposure on its EHR entity and a related identity-provider entity that issues clinician SSO. What IRM configuration best captures that the EHR risk depends on the identity provider's posture?
Select an answer to reveal the explanation.
Short Explanation
If the clinic's login keys fall over, the EHR risk gets worse — those two risks are hitchhikers. Relating them as dependent related risks keeps that story visible without smushing two entities into one fake CI. Unrelated duplicates hide the chain.
Full Explanation
Ransomware exposure that spans an EHR entity and a related identity-provider entity issuing clinician SSO is best captured by relating those risks with a dependency-style related-risk relationship. Related-risk links preserve separate entity and risk records while making cascading posture visible—if identity weakens, EHR residual context worsens. Civic clinical architectures routinely need that dependency story without merging CIs incorrectly.
Merging both entities into one CMDB CI class so only a single risk can exist falsifies the CMDB and destroys distinct ownership. Ignoring identity risk because authentication is supposedly out of GRC scope by blueprint rule is false and leaves a critical dependency untracked. Duplicating the EHR risk statement onto the identity entity with no relationship creates parallel orphans without an explicit dependency.
Exam caveat: related-risk relationships express dependency; entity merge and unlinked duplicates do not. CIS-RC favors explicit risk-to-risk links for cascading civic tech stacks.
Operational check: create or confirm EHR and IdP risks; add a dependency-style related-risk link; demonstrate the relationship on residual discussions; keep separate entities and owners.