Governance, Risk, and Compliance (GRC)

A supplier hands you an ISO/IEC 27001 certificate, a framework crosswalk, and a signed contract clause, then asks you to confirm the system is compliant. None of the three settles it on its own, because governance, risk, and compliance (GRC) works as a chain of four links, a mental model this page routes by: the authority that makes an obligation binding, which is a law, regulation, directive, contract, or internal policy, among others, and never a framework's reputation; the requirement that survives once you test that obligation against this system's mission, jurisdictions, data, and scope boundary; the decision an accountable owner, the official with authority to accept risk, takes on what treatment leaves behind (the residual risk); and the evidence the architecture keeps producing so an assessor can walk the chain back to its source. The trap the chain helps you dodge is mistaking an input for an answer: a crosswalk indicates a relationship rather than control equivalence, a certificate is bounded by its certified scope, and a Common Vulnerability Scoring System (CVSS) score is one input to a risk determination, not the determination itself. This domain carries 21% of the exam, the smallest share of the four, and still the frame the other three are graded against.

Read this page as a map, then take the subtopics in that order. Identify Security Requirements covers the first two links: it names the authority behind each claimed requirement, sorts what follows into four families (standards and guidelines, third-party and contractual obligations, personal-data and privacy law, and resilience requirements), tests applicability against this organization's context, not the standard's fame, and draws the scope boundary that every downstream control is measured inside, including the business impact analysis numbers that bound recovery. Architect for Governance, Risk, and Compliance covers the last two: it gives asset, information, and risk owners real decision rights, turns risk assessment artifacts into treatment options the accountable owner can act on, and designs auditability and continuous monitoring so the system keeps producing proof long after its first assessment. Evidence sits on both sides: the first names the proof a requirement demands, the second builds what keeps producing it. Reach for the first subtopic when the open question is whether something binds you, the second when it is who decides and how you would show it.

The instinct this domain rewards runs in one specific direction: work moves, accountability does not, and nothing counts until it is evidenced. An organization keeps responsibility for the obligations attached to its mission and information even when a supplier performs the work, so an option that reads a provider certification, an insurance policy, or a flowed-down contract clause as a transfer of accountability is almost always the distractor. The same instinct fixes your own seat in the picture: the architect states the exposure, the treatment options, and the residual risk each option leaves behind, while the accountable owner makes the call. Between two technically workable answers, prefer the one that names an owner, states a scope, and produces a record that would still prove the point a year later.