# Stage 2: How do you define minimum viable GRC scope?

**Choose one end-to-end workflow, including its exceptions and reporting—not a collection of disconnected modules.**

For example, a controls-first release could include:

1. A controlled library of obligations and control objectives.
2. Entity-specific control implementations and accountable owners.
3. Evidence requests and review.
4. Testing outcomes.
5. Findings, remediation and approved exceptions.
6. One management report with traceable underlying records.

Defer other workflows unless they are necessary to make that first process usable. Record the deferred work so it does not return as an undocumented configuration request.

### What must stakeholders agree before configuration?

Use a design decision log to settle:

| Decision | Question to resolve |
|---|---|
| Entity structure | Are risks and controls attached to legal entities, business units, services, applications or combinations? |
| Risk methodology | Who sets scales, challenges assessments and approves overrides? |
| Control ownership | Is this a shared control, a local implementation or a genuinely distinct control? |
| Testing | Who performs management testing, who reviews it and what does audit independently assess? |
| Exceptions | Who may accept an exception, for how long, with what review and expiry process? |
| Remediation | Who owns an action, who can extend it and who verifies closure? |
| Reporting | Which records are included, excluded or not yet assessed? |
| Evidence | Who may see, reuse, download and retain each class of material? |

For cybersecurity-led scope, NIST provides a free spreadsheet template for comparing **Current and Target CSF 2.0 Organisational Profiles**. Use it to structure desired outcomes and gaps; do not substitute a framework mapping for a legal-applicability decision. ([nist.gov](https://www.nist.gov/cyberframework/profiles?utm_source=openai))

### How do US sector requirements change platform selection?

**Create an applicability register with counsel and the relevant functional owner.** The table below identifies evidence to consult and proposed procurement consequences; it is not a complete legal checklist.

| Buyer situation | Verified regulatory or professional context | Proposed platform requirement |
|---|---|---|
| Bank evaluating a material GRC supplier | The banking agencies’ community-bank guide covers considerations throughout the third-party relationship lifecycle and is voluntary guidance tailored to risk and complexity. ([occ.gov](https://www.occ.gov/news-issuances/bulletins/2024/bulletin-2024-11.html?utm_source=openai)) | Retain diligence, approvals, contract obligations, monitoring and termination evidence for the GRC supplier itself |
| Nonbank financial business | FTC Safeguards Rule coverage depends on activities and FTC jurisdiction; it is not a blanket rule for every organisation described as financial services. ([ftc.gov](https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know?utm_source=openai)) | Record applicability by entity and activity, with the relevant safeguards and accountable owner |
| Healthcare organisation storing ePHI | HHS states that a cloud provider creating, receiving, maintaining or transmitting ePHI on a covered entity’s behalf is a business associate, including where it lacks the encryption key. A compliant BAA is required. ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html?utm_source=openai)) | Decide whether ePHI needs to enter GRC at all; if it does, resolve the BAA, permitted use, safeguards and access design before upload |
| Public-company ICFR programme | SEC guidance places responsibility on management to determine appropriate controls and assessment scope, supported by evidence. ([sec.gov](https://www.sec.gov/info/accountants/stafficreporting.htm?utm_source=openai)) | Preserve control versions, testing periods, review, deficiencies and management assessment evidence |
| NYDFS-covered entity | The published implementation timeline set **1 November 2025** for expanded MFA and asset-inventory provisions, subject to applicable exemptions and compensating-control provisions. That date is already past. ([dfs.ny.gov](https://www.dfs.ny.gov/industry_guidance/cybersecurity/implementation_timeline_covered_entities)) | Demonstrate the relevant access controls and the traceability of asset-related obligations; do not describe these provisions as a future implementation deadline |

For each applicable obligation, record the authority, version, legal entity, interpretation owner, implementation requirement, evidence expectation and review date. Ask the supplier to distinguish included content from separately licensed content and buyer-maintained mappings.

**Exit gate:** release-one scope, decision rules and regulatory applicability have named approvers; unresolved legal interpretations are not disguised as software requirements.