How the pieces fit together

Every GRC record is useful on its own but valuable in combination. The diagram below shows the relationship graph; the text that follows explains each link in plain English.

Key links in plain English:

• A control can be mapped to many framework sections, and many controls can cover one section. Together they drive gap analysis ("how much of NIST CSF PR.AA do we cover?").
• A control mitigates one or more risks; conversely one risk can be covered by several controls. This is what lowers a risk's residual score from its inherent score.
• A control test records whether the control worked when exercised — pass / fail / partial. Test records can reference the evidence that was reviewed.
• Evidence (files in R2) can be linked to a control or a policy, optionally both. This is the artefact chain auditors walk.
• A policy implements one or more controls and addresses one or more risks. A policy can be published into an attestation campaign that tracks user acknowledgments.
• An asset can be linked to risks it's exposed to. A vulnerability can reference an affected asset, a related control, and an associated risk.
• An incident can be linked to the risks it materialised. Post-incident, that linkage evidences whether your controls were effective.
• A vendor has a list of data types it processes (PII, payment, health, …), which drives DPA / GDPR / HIPAA applicability automatically.

If you remember one rule: never add a control, policy, or piece of evidence without immediately linking it to the upstream item it exists for. Unlinked records are landfill; linked records are the audit story.