# Do-it-yourself game plans

Controlspan Research Desk · Last updated 28 October 2026

# What is the shortest honest answer?

**Run the purchase as an operating-model and data programme, with software selection inside it—not as a software demonstration followed by an import.** Establish the first workflow, decision rights, data model, migration treatment, acceptance tests and operating capacity before committing to a platform. This approach is consistent with KPMG’s published GRC implementation guidance, which separates business readiness, data rationalisation, migration, testing and post-production support. ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf))

This guide supplies a buyer-led route through twelve stages:

1. Establish the decision, sponsor and business case.
2. Define the first useful scope and regulatory applicability.
3. Inventory and clean the data.
4. Write requirements and obtain comparable proposals.
5. Test shortlisted platforms using your own scenarios.
6. Complete security, commercial and contractual diligence.
7. Configure the agreed operating model.
8. Build and prove integrations.
9. Rehearse migration and complete acceptance testing.
10. Cut over without losing accountability or evidence.
11. Establish sustainable administration and adoption.
12. Maintain renewal and exit readiness.

**DIY means retaining ownership of these decisions.** It need not mean refusing all external assistance. You can commission a narrow architecture review, difficult migration component or security assessment while keeping the requirements, configuration register, acceptance evidence and operating model under your control.

### How should you read the evidence and estimates?

- **Verified facts** are cited to public regulator guidance, professional bodies, supplier documentation, public procurement material or an employer’s job posting.
- **Supplier statements** establish what a supplier publishes, not what this desk has independently tested.
- **The checklists, scorecards, test cases, staffing allocations and financial examples are proposed buyer methods.** They are not industry benchmarks or regulatory prescriptions.
- **The illustrative schedule is 42 weeks from mobilisation to stabilisation.** It is not a measured average.
- No private quotations, customer interviews or hands-on platform tests were available for this document. The supplied desk’s unverified market-size and broad price estimates are therefore not repeated as established facts.

Confirm legal applicability, retention decisions and contract language with your organisation’s US counsel and regulatory specialists.

---

# Should you repair, configure, buy or build?

**Keep all four options open until the first workflow and its failure points are understood.** Use the following decision test before issuing a GRC RFP.

| Route | Consider it when | What your team must still do | Recommended stop condition |
|---|---|---|---|
| Repair the incumbent | You can demonstrate that ownership, configuration or data quality—not an essential capability gap—is the principal problem | Redesign the process, cleanse data, simplify configuration and retest reporting | A mandatory workflow or permission boundary cannot be supported acceptably |
| Configure an existing enterprise platform | Your organisation already has relevant platform skills and an approved architecture | Verify additional entitlements, module fit, administration and integration capacity | Existing platform ownership is being mistaken for entitlement or domain capability |
| Buy a specialist or enterprise GRC product | The first workflow needs capabilities you cannot reasonably deliver with existing tools | Select, configure, migrate, test, train and operate it | No one will own the system after launch |
| Build a bounded internal application | Requirements are narrow, stable and supported by a funded engineering owner | Own the data model, access rules, workflow, evidence handling, testing, support and exit format | The project is expanding into a general-purpose enterprise GRC product without corresponding engineering capacity |

If you choose the internal-build route, do not bypass the remaining stages. Replace the supplier evaluation with a build-design review, and require the same permission, audit-history, recovery, integration and portability tests.

For a build experiment, start with **one controlled register and one approval workflow**, not an attempted replacement for enterprise risk, SOX, internal audit and third-party risk simultaneously. Treat expansion as a separate funding decision.

---

# Who must be involved, and who should you contact?

**Name the future operating team before shortlisting.** Separate ownership of business decisions from platform administration and independent assurance.

The IIA’s refreshed Three Lines Model distinguishes management’s responsibility for operating processes and controls, second-line support and challenge, and internal audit’s independent assurance role. Its updated statements were published on **8 July 2026**. A shared platform should preserve those distinctions rather than erase them. ([theiia.org](https://www.theiia.org/globalassets/site/resources/statements-of-position/tlm_assurance_advice_support_effective_gov_en.pdf))

### What responsibilities should the buyer assign?

The following is a proposed responsibility map, not a mandatory organisational structure.

| Role | Accountable contribution | Contact them for |
|---|---|---|
| Executive sponsor | Scope, funding, unresolved cross-functional decisions | Business-case approval and escalation authority |
| GRC programme lead/product owner | Integrated plan, backlog, dependencies and acceptance coordination | Day-to-day delivery decisions |
| Risk, compliance or controls process owner | Taxonomy, scoring, approvals and workflow rules | Business design and acceptance |
| Data steward and record owners | Source quality, mappings and reconciliation | Migration readiness and exception resolution |
| Platform administrator plus deputy | Configuration, access, releases and support | Maintainability and handover |
| Enterprise architect and integration owners | Architecture, source-system responsibilities and interfaces | Integration feasibility and support boundaries |
| Security and privacy leads | Data classification, access, supplier assurance and incident arrangements | Security approval |
| Internal audit | Assurance requirements and appropriate independent challenge | Evidence sufficiency and independence safeguards |
| Procurement, finance and legal | Quote normalisation, affordability and contractual protection | Commercial approval and negotiation |
| Representative business contributors | Practical completion of tasks | Usability and adoption testing |

**Do not make internal audit the default owner of management’s risk decisions simply because audit initiated the purchase.** Agree any advisory role and safeguards explicitly. ([theiia.org](https://www.theiia.org/globalassets/site/resources/statements-of-position/tlm_assurance_advice_support_effective_gov_en.pdf))

### Which supplier-side people should you request?

Ask the account executive to bring the people responsible for delivery and operation—not only the demonstrator:

- A solution architect who can explain the proposed object model and access design.
- The proposed delivery lead, including subcontracting arrangements.
- A migration specialist who can address attachments, history and reconciliation.
- An integration engineer who can demonstrate failure handling.
- A commercial specialist authorised to clarify licence categories and expansion terms.
- A support or customer-success representative who can explain the post-launch boundary.
- Customer references with a comparable first workflow and operating model.

For references, request a conversation with an administrator or programme owner, not only the executive sponsor. Ask what they maintain themselves, what still requires services, and which original assumptions changed.

### How much internal capacity should you reserve?

Build a task-based estimate. Do not infer staffing from employee count alone.

As a reality check, a First Horizon Senior GRC Administrator posting dated **9 April 2026** describes responsibilities spanning configuration governance, data integrity, release control, integration validation and production stability. That is evidence of the breadth of one advertised role—not proof that every buyer needs the same headcount. ([recruiting.ultipro.com](https://recruiting.ultipro.com/FIR1007FTN/JobBoard/c005ef3e-175a-49c4-ba29-9f431f673944/OpportunityDetail?opportunityId=3d3259bf-0bb5-474b-8eb4-639fe8f63a6b&utm_source=openai))

The cost illustration later in this guide uses this **synthetic 2,800-hour selection and delivery allocation**:

| Workstream | Illustrative internal hours |
|---|---:|
| Programme management and product ownership | 600 |
| Process design and data stewardship | 600 |
| Platform configuration and administration | 600 |
| Architecture, security and integrations | 450 |
| User acceptance, training and contributor participation | 350 |
| Procurement, legal and finance | 200 |
| **Total** | **2,800** |

Replace every allocation with named people, available hours and a manager-approved commitment. If those commitments cannot be secured, reduce scope or change the delivery model before signing.

---

# How long does enterprise GRC implementation take?

**Separate selection, supplier implementation, buyer readiness and stabilisation. They are different clocks.**

For one concrete supplier example, LogicGate publishes approximate implementation durations ranging from **30 days for Lite to 150 days for Elite**, with intermediate packages. Its services description states that each implementation option covers **one Application**. Those are supplier-described package timelines, not evidence that a multi-function enterprise programme can be selected, migrated and adopted in the same period. ([logicgate.ai](https://www.logicgate.ai/services-description/))

### What does a usable GRC implementation project plan look like?

The following **42-week planning example** assumes a phased deployment, an available internal team and a limited first release. Activities overlap deliberately.

| Stage | Illustrative window | Principal document | Approval before proceeding |
|---|---|---|---|
| 1. Mobilise | Weeks 1–2 | Decision charter and baseline | Sponsor accepts the problem and decision rights |
| 2. Define scope | Weeks 3–6 | Scope charter and applicability register | Process owners approve release-one boundaries |
| 3. Prepare data | Weeks 4–10, continuing as needed | Data inventory, dictionary and remediation backlog | Migration method is credible |
| 4. Requirements and proposals | Weeks 7–12 | RFP and commercial response workbook | Comparable shortlist evidence exists |
| 5. Demonstrations and proof of concept | Weeks 11–16 | Scenario results and decision log | Mandatory requirements are proven or resolved |
| 6. Diligence and contracting | Weeks 13–18 | TCO, contract schedules and delivery scope | Security, finance, legal and sponsor approve |
| 7. Detailed design and foundations | Weeks 19–24 | Design baseline and configuration register | Data and access designs are accepted |
| 8. Build and integrate | Weeks 25–32 | Configurations and interface runbooks | Technical tests pass |
| 9. Rehearse and accept | Weeks 29–36 | Migration reconciliation and UAT results | Business and technical acceptance gates pass |
| 10. Cut over | Weeks 37–38 | Cutover, rollback and communications plans | Named go/no-go authority approves |
| 11. Stabilise | Weeks 39–42 | Support handover and operating backlog | Operating team accepts ownership |
| 12. Renew or exit | Ongoing | Portability tests and renewal calendar | Decision occurs before notice deadlines |

**Do not compress this example by deleting testing or migration rehearsal.** If a deadline is fixed, reduce the first release and establish an interim control process for excluded work.

Build your actual critical path around five dependencies: approval lead times, data cleansing, source-system access, supplier delivery availability and the earliest safe cutover window. KPMG’s implementation guidance specifically calls for resource allocation, integrated testing, access validation and explicit go/no-go criteria. ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/pathway-technology-alignment.pdf))

---

# Stage 1: What decision are you actually trying to make?

**Write a two-page decision charter before inviting demonstrations.** The purpose is to distinguish a software problem from a process, data or staffing problem.

### What should the charter contain?

Use these fields:

- **Trigger:** examination finding, control deficiency, renewal, acquisition, reporting requirement or operational bottleneck.
- **Current failure:** a specific activity that does not work adequately.
- **Affected population:** entities, functions, users and records.
- **First outcome:** what should be demonstrably different after release one.
- **Decision deadline:** including the reason it is fixed.
- **Alternatives:** retain, repair, configure, buy or build.
- **Sponsor and decision rights:** who resolves conflicting requirements.
- **Funding boundary:** selection, delivery and ongoing operation.
- **Exclusions:** work explicitly outside the first release.
- **Success evidence:** the report, transaction or completed process that will prove usefulness.

A good first outcome is specific: *A control owner can submit evidence, a reviewer can challenge it, a failed test creates an accountable action, and the committee report traces back to those records.*

An insufficient outcome is: *Create a single source of truth.*

### How do you establish a baseline?

Measure the existing workflow before changing it. Suggested measures include:

- Time spent requesting and chasing evidence.
- Elapsed time from submission to review.
- Records without an accountable owner.
- Actions overdue under the current policy.
- Time required to reproduce the committee report.
- Requests that need manual reconciliation between systems.
- Costs of retained tools and external support.

Define the denominator and observation period. Separate labour capacity from avoidable expenditure: a reduction in task time is not a payroll saving unless finance identifies an actual cash consequence.

**Exit gate:** the sponsor can explain the problem, the first outcome, the alternatives and the person responsible for operating the result.

---

# 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.

---

# Stage 3: How do you clean a risk register before GRC migration?

**Create a controlled source inventory and preserve the original data before deduplicating anything.** Your first migration deliverable should be a defensible mapping, not a cleaned spreadsheet with no record of what changed.

### What should the GRC data migration checklist cover?

Inventory each source separately:

- Spreadsheets and local databases.
- Existing GRC modules.
- Document and evidence repositories.
- Ticketing and remediation systems.
- Identity and organisational reference data.
- Regulatory-content libraries.
- Reporting extracts and archived committee packs.

For every source, record its business owner, technical custodian, extraction method, record volume, attachment volume, sensitivity, update frequency, retention treatment and known quality problems. Record extraction dates and preserve a read-only original.

### What target data structure should you propose?

Use this as a **vendor-neutral starting model**, then map it to the selected product’s supported design.

| Object | Minimum proposed fields | Relationships to preserve |
|---|---|---|
| Entity | Stable ID, type, name, parent, owner, active dates | Processes, services, applications and legal entities |
| Obligation | Authority, citation, version, effective date, applicability owner | Policies, control objectives and entities |
| Risk | Stable ID, statement, category, owner, entity, assessment date, methodology version | Assessments, controls, events and actions |
| Control objective | Stable ID, intended outcome, scope and version | Obligations and control implementations |
| Control implementation | ID, objective, entity, operator, reviewer, frequency and status | Evidence, tests, exceptions and findings |
| Test or assessment | Period, procedure, performer, reviewer, outcome and approval | The version of the object assessed and its evidence |
| Evidence | ID, source, file or reference, period, classification and custodian | Relevant tests and controls, with access restrictions |
| Finding or issue | ID, description, severity, origin, owner and status | Controls, risks, tests and remediation |
| Action or exception | Owner, approver, due or expiry date, rationale and closure evidence | Finding, control or risk |

### How should you handle duplicates and local variants?

Do not merge records solely because their titles match. Compare the activity, entity, owner, frequency, population, procedure and evidence.

**Synthetic example:**

| Source record | Proposed treatment | Reason |
|---|---|---|
| Access review — Retail — quarterly | Retain local implementation | Local population and owner |
| Access review — Insurance — quarterly | Retain local implementation under the same objective | Similar purpose, different execution |
| Duplicate of Retail record with the same population and period | Merge only after owner approval | Possible duplicate, requiring confirmation |
| Central identity-service review relied on by both entities | Model shared ownership and reliance separately | A centrally operated control is not the same as two locally operated controls |

ServiceNow’s Australia documentation explicitly supports common controls and reliant entities. It also notes that, for the described risk-control relationships, only active relationships are maintained and historical ones are removed. That is a reason to test point-in-time reporting and retained history in the proposed configuration—not to assume that a current relationship view is a historical record. ([servicenow.com](https://www.servicenow.com/docs/r/governance-risk-compliance/grc-risk-management-workspace/shared-common-controls-in-risk-management.html?utm_source=openai))

For risk ratings, preserve the original value, scale and assessment date. Do not convert every legacy “high” into one new numeric value without an approved mapping and a record of the transformation.

### How do you migrate audit evidence and control history?

Choose a treatment for each record class:

1. **Migrate as active records:** items needed for ongoing work.
2. **Migrate as historical records:** material needed inside the new workflow or reporting model.
3. **Retain in a controlled archive:** material that must remain retrievable but need not be recreated as live transactions.
4. **Dispose under an approved schedule:** only after retention and legal-hold checks.

Keep source IDs and original dates separately from new-system creation metadata. Require a historical retrieval demonstration before accepting the archive strategy.

IBM’s OpenPages 9.1 FastMap documentation illustrates why this matters: FastMap does not import attachments or signatures, and it cannot preserve system creation-date information through that process. These are limitations of that import route, not proof that OpenPages has no other migration options. ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview&utm_source=openai))

For HIPAA Security Rule documentation, HHS states that required documentation must be retained until six years after creation or the date it was last in effect, whichever is later. Do not turn that into an unsupported six-year rule for every record or technical log in the organisation. ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html?form=MG0AV3))

### What evidence proves migration readiness?

Create a defect register containing source record, defect, business consequence, treatment, owner, due date and approval. Suggested pre-contract checks are:

- Stable IDs exist or can be assigned repeatably.
- Critical records have confirmed owners.
- Parent-child and many-to-many relationships are understood.
- Attachment extraction has been tested.
- Historical treatment has been approved.
- Restricted evidence has a target access design.
- A sample can be loaded, reconciled and exported again.

A sample proves only what was tested. Use deliberately difficult records—missing owners, long text, reopened findings, inherited controls and restricted attachments—rather than only clean rows.

**Exit gate:** the team can explain what will move, what will remain archived, what will change and how each decision will be reconciled.

---

# Stage 4: What belongs in an enterprise GRC software requirements checklist and RFP?

**Write requirements as observable behaviour, with an owner and acceptance method.** Avoid requests such as “supports enterprise risk” unless followed by a specific workflow.

### What is a usable requirement format?

| Field | Example |
|---|---|
| Requirement ID | REM-014 |
| Business outcome | An overdue high-priority action receives accountable escalation |
| Scenario | The owner misses the due date and then requests an extension |
| Required behaviour | Preserve the original date, record the reason, route approval and update reporting without hiding lateness |
| Priority | Mandatory for release one |
| Owner | Head of Compliance |
| Acceptance | Demonstrate with supplied synthetic records and retain the resulting history |
| Supplier response | Supported configuration, custom development, third party, roadmap, not demonstrated or unavailable |
| Commercial dependency | Identify module, licence, integration and services implications |

Include requirements for data, security, reporting, administration, integration, migration and exit—not just end-user functions.

### What should the RFP pack contain?

Prepare these eight documents:

1. Scope charter and explicit exclusions.
2. Process diagrams and decision rules.
3. Requirements workbook.
4. Data inventory and redacted sample.
5. Architecture and interface register.
6. Demonstration script and acceptance criteria.
7. Commercial response workbook.
8. Draft delivery, support and exit requirements.

Request separate prices for the first release, optional later phases and ongoing support. Require assumptions and buyer responsibilities beside every services estimate.

A recent public example shows why scope discipline matters: EPB’s August 2026 GRC solicitation sought internal audit, enterprise risk, compliance and third-party management in one procurement. That demonstrates the breadth of that buyer’s requirement, not that every buyer should launch all those workflows together. ([business.epb.com](https://business.epb.com/competitive-sealed-bids-request-for-proposals/))

### How should you weight the evaluation?

Apply mandatory gates first. A high feature score should not offset an unacceptable security, legal or portability issue.

**Suggested starting weights—not a validated universal scoring model:**

| Scored category | Weight |
|---|---:|
| Release-one workflow and specialist depth | 25% |
| Migration and evidence integrity | 20% |
| Administration and contributor usability | 15% |
| Integration and architecture | 15% |
| Three-year ownership cost and commercial flexibility | 15% |
| Delivery capability and reference evidence | 10% |
| **Total** | **100%** |

Score demonstrated evidence separately from confidence. Record a capability as **not demonstrated** when it was not shown; do not silently treat it as either proven or unavailable.

### How should you approach named-platform comparisons?

For searches such as **ServiceNow IRM vs Archer vs IBM OpenPages**, compare the same data model, restricted-evidence case, integration failure and export test. Do not compare one supplier’s configured environment with another’s unconfigured baseline without recording that difference.

For **AuditBoard vs Workiva**, note the naming change: AuditBoard announced its rebrand to **Optro on 9 March 2026**. Use “Optro, formerly AuditBoard” in the evaluation register so historical references and current proposals are not mistaken for separate suppliers. ([optro.ai](https://optro.ai/blog/meet-optro-auditboard-unveils-new-identity-as-ai-transforms-grc?utm_source=openai))

**Exit gate:** shortlisted suppliers have answered the same scoped requirement and commercial questions; unresolved items have owners and dates.

---

# Stage 5: What should you make shortlisted suppliers demonstrate?

**Use a buyer-owned scenario pack and retain the evidence.** Request the proposed edition, modules and relevant configuration—not an unspecified demonstration tenant.

KPMG’s GRC guidance calls for end-to-end positive and negative testing, including access validation. The following is a proposed practical test pack built around that principle. ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/pathway-technology-alignment.pdf))

### What should the demonstration script include?

| Test | What the supplier should do | Suggested pass evidence |
|---|---|---|
| End-to-end control lifecycle | Assign a control, request evidence, reject it, resubmit, test and raise a finding | Linked records, owners, dates and review history |
| Overdue remediation | Miss a due date, request an extension and escalate | Original deadline remains visible; approval and reporting are correct |
| Disputed risk score | Have a reviewer challenge an assessment | Original assessment, challenge, rationale and authorised final decision remain traceable |
| Shared-control failure | Fail a centrally operated control used by multiple entities | Reliance and affected reporting are visible without unauthorised evidence disclosure |
| Restricted evidence | Attempt access as an unrelated user through UI, search, report, download, API and AI | Access is denied consistently under the agreed model |
| Failed integration | Expire credentials or interrupt a feed | Failure is visible; stale data is identified; recovery does not create duplicates |
| Departed owner | Disable an owner and reassign outstanding work | Historical attribution remains intact and current work has an owner |
| Ordinary administration | Have your administrator change a reminder or approved field in a test environment | Change can be documented, tested and reversed using the proposed support model |
| Historical reporting | Reproduce an agreed prior-period result after current data changes | Report population, methodology and relevant versions are explainable |
| Bulk exit | Export the supplied records, relationships, attachments and relevant history | Your team reconstructs the agreed sample outside the platform |

Give contributors real tasks rather than asking whether the interface looks intuitive. Record time, errors, help requests and unfinished steps. Agree your acceptable thresholds before testing.

### How should you test AI-enabled GRC?

**Treat AI as an optional, separately accepted workflow component.** NIST’s Generative AI Profile identifies risks including confabulation, data privacy, information integrity, information security and problematic human reliance. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf?utm_source=openai))

Use a synthetic evaluation set containing:

- Two similarly named controls with different scopes.
- An obsolete policy and its replacement.
- A document containing a deliberately incorrect statement.
- Evidence the test user is not authorised to access.
- A question for which the supplied material contains no answer.
- A document containing instructions that should be treated as document content, not executed.

Require source traceability, uncertainty handling, permission enforcement and an explicit human approval step before consequential changes. Test permission revocation as well as initial access.

Measure:

- Correctness against an approved answer set.
- Unsupported assertions.
- Restricted-information exposure.
- Reviewer correction time.
- Total task time, including review.
- Behaviour after a model or product change.

Do not treat a clean demonstration as a statistical assurance of safety. Record the dataset, version, settings, failure criteria and limitations. If an AI feature fails, assess whether it can remain disabled without preventing the core purchase.

### What should a proof of concept produce?

Retain a dated pack with configuration details, test data, test identities, recordings or logs where permitted, observed results, defects, remediation commitments and retest outcomes. Require the supplier to identify any work performed outside the quoted configuration.

**Exit gate:** mandatory scenarios pass, or a formally approved resolution is completed before contractual reliance. Roadmap statements are not acceptance evidence.

---

# Stage 6: How do you complete security, commercial and contractual diligence?

**Evaluate the proposed service, its delivery partners and your own operating design together.** The bank third-party lifecycle guidance is a useful organising reference for banking buyers; use your own supplier-risk process for applicability and depth. ([occ.gov](https://www.occ.gov/news-issuances/bulletins/2024/bulletin-2024-11.html?utm_source=openai))

### What security evidence should you request?

Use the following proposed request list, tailored to the information you will store:

- Service and data-flow architecture, including subprocessors.
- Hosting, support-access and cross-border processing arrangements.
- Relevant independent assurance reports and the scope they actually cover.
- Identity federation, provisioning, MFA and privileged-access design.
- Record, attachment, search, reporting and API permission behaviour.
- Encryption and key-management responsibilities.
- Logging, monitoring and incident-notification arrangements.
- Backup, restoration and disaster-recovery evidence.
- Vulnerability management and material-change notification.
- Data return, deletion, retention and legal-hold treatment.
- AI subprocessors, data-use terms, retention and opt-out controls where applicable.

Do not equate a successful user-interface permission test with safe bulk-export permissions. IBM’s OpenPages 9.1 Data Export documentation warns that the specified administrative export permission can export data regardless of role-based security and other listed access settings. Verify the exact deployment and constrain export authority accordingly. ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications&utm_source=openai))

### How do you compare enterprise GRC software pricing?

**Normalise the commercial unit before comparing the dollar amount.** Ask each supplier to price the same modules, entities, environments, interfaces and user actions.

Public sources illustrate why a universal per-user assumption is unsafe:

- LogicGate describes pricing by Applications and Power Users; its pricing page says Standard and External user licences are included without additional charge. Optional capabilities and services are additional components. ([logicgate.ai](https://www.logicgate.ai/platform/pricing/?utm_source=openai))
- IBM publishes OpenPages starting figures for different deployment and edition options, but the headline pricing page does not state the billing period beside those figures. It also flags edition-specific limitations and additional-cost AI capabilities. Do not annualise a headline amount without written clarification. ([ibm.com](https://www.ibm.com/products/openpages/pricing))

Build a licence matrix using actions, not job titles:

| User or system activity | Question for the supplier |
|---|---|
| Build forms and workflows | Which administrative entitlement is required? |
| Assess risks or perform tests | Which full-use entitlement is required? |
| Submit evidence occasionally | Is this included, separately licensed or restricted? |
| Approve an exception | Does approval change the required licence? |
| View dashboards or export data | Are viewing and exporting treated differently? |
| Complete an external questionnaire | How are external identities and access licensed? |
| Run integrations | Are service accounts, API calls or connector transactions charged? |
| Use AI | Is charging by module, user, consumption or another measure? |

Request written answers for sandbox access, storage, attachment limits, content subscriptions, premium support, integrations, overages, affiliate use, acquisitions, expansion and renewal increases.

### How much does a DIY GRC implementation cost?

**There is no defensible universal total in the public evidence reviewed. Build a bottom-up model using your quotes and workload.**

The following is a **synthetic financial scenario**, not a price benchmark, quotation or forecast. It assumes a 36-month software term, six months of implementation and stabilisation within that term, and 30 subsequent months of steady-state administration. Attributable selection labour is included as an acquisition cost. All values are USD.

| Cost line | Explicit illustrative assumption | Three-year amount |
|---|---|---:|
| Core subscription | $150,000 in year one; assumed 5% annual increase | $472,875 |
| Targeted external assistance | 300 hours × assumed $200/hour | $60,000 |
| Internal selection and delivery | 2,800 hours × assumed fully loaded $85/hour | $238,000 |
| Training budget | Assumed one-off allowance | $10,000 |
| Additional integration/content/environment charges | Assumed $12,000 annually, not included in core subscription | $36,000 |
| Legacy overlap | Six months × assumed $5,000/month | $30,000 |
| Steady-state administration | 100 hours/month × 30 months × assumed $85/hour | $255,000 |
| **Modelled ownership cost** | **External expenditure plus internal labour** | **$1,101,875** |

The model contains **$608,875 of external expenditure** and **$493,000 of internal labour**. Existing salaries are not necessarily incremental cash expenditure; backfill or new hiring may be. Keep those views separate in the approval pack.

The apparent precision comes from arithmetic, not certainty. Taxes, an optional exit, additional modules and unquoted overages are excluded and must be separately resolved. Do not enter missing costs as zero.

For one published training reference, Learning Tree lists a three-day ServiceNow GRC/IRM implementation course at **$2,700**, including an exam voucher. That is a course price—not a complete training programme or proof of implementation competence. ([learningtree.com](https://www.learningtree.com/courses/servicenow-grc-irm-implementation-training/))

### Which assumptions should you stress-test first?

| Change to the synthetic model | Additional cost |
|---|---:|
| 20% more internal selection/delivery hours: 560 × $85 | $47,600 |
| 50 additional administration hours per month for 30 months | $127,500 |
| Six additional months of retained legacy access at $5,000/month | $30,000 |

Also test licence expansion, a delayed integration and additional migration rehearsals using supplier-specific rates. Show contingency separately from expected expenditure, and assign each uncertainty an owner who can reduce it.

Do not assume that deleting the external-assistance line produces an equivalent saving. Re-estimate the internal work and capability needed to replace that assistance.

### What should the contract and statement of work contain?

Take this proposed checklist to procurement and counsel:

- Exact products, editions, deployment, user rights and environments.
- Deliverables mapped to requirements and acceptance tests.
- Migration objects, attachments, history, exclusions and reconciliation duties.
- Named buyer dependencies and dates.
- Integration responsibilities across supplier, partner and source-system owner.
- Configuration documentation and rights to use custom deliverables.
- Change-control rules, rates and approval authority.
- Support coverage, response expectations and escalation.
- Security, privacy, incident and subprocessor arrangements.
- Renewal, uplift, expansion and notice provisions.
- Export format, access period, assistance rates and deletion arrangements.
- Remedies and responsibilities if acceptance is not achieved.

For banking buyers, the 2023 interagency guidance explicitly addresses orderly transition, return or destruction of data, and allocation of transition and termination costs. These are procurement issues to resolve before dependency grows. ([occ.gov](https://www.occ.gov/news-issuances/federal-register/2023/88fr37920.pdf))

**Exit gate:** no unresolved critical security issue; a funded operating model; understood licence rights; and an agreed delivery and acceptance boundary.

---

# Stage 7: How do you configure without creating permanent consultant dependency?

**Make every configuration decision explainable and maintainable by the future operating team.**

Start with the approved entity model, reference data, user roles and workflow decisions. Build the simplest supported configuration that passes release-one acceptance. Require a written justification for custom code or unsupported workarounds.

### What should the configuration register contain?

For each change, record:

- Business requirement and owner.
- Object, field, rule, workflow or report affected.
- Supported configuration versus custom development.
- Dependencies and access implications.
- Test evidence and approval.
- Deployment and rollback method.
- Maintainer and support boundary.
- Upgrade or regression-test obligation.

Use the proposed production access model in testing. Avoid proving the process only through an administrator account.

### How do you prepare administrators?

Require the administrator and deputy to complete realistic tasks without supplier intervention: reassign ownership, add an approved field, amend a reminder, diagnose a failed job, deploy a tested change and export the agreed data pack.

ServiceNow’s January 2026 implementation-specialist blueprint covers configuration, implementation and maintenance across risk, policy/compliance and audit applications. Its supplier-produced Risk Speed Learning material also provides configuration walkthroughs and linked YouTube playlists. Use such materials to build platform-specific skills, then test those skills against your design. ([learning.servicenow.com](https://learning.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0011655&utm_source=openai))

**Exit gate:** the buyer’s administrators can explain the design and perform the agreed routine changes; documentation is usable rather than merely delivered.

---

# Stage 8: How do you prove integrations and continuous evidence collection?

**Specify an integration as a supported business process, not as a connector name.**

Archer’s current IT Security Risk Management integration guide distinguishes REST APIs, scheduled data feeds and one-time imports. It explains that API integrations require an intermediary to handle functions such as authentication, transformation and scheduling, while the one-time importer is not the mechanism for ongoing automated integration. ([help.archerirm.cloud](https://help.archerirm.cloud/archersolutions/en-us/Content/ArcherSolutions/itsrm_integration_guide.htm))

### What belongs in the integration dependency register?

Use one row per interface:

| Field | Required decision |
|---|---|
| Purpose | Which control, report or workflow depends on the interface? |
| Source of truth | Which system owns each relevant field? |
| Direction | Read-only, write-back or explicitly governed bidirectional flow? |
| Scope | Which objects, fields, attachments and populations are included? |
| Identity | Which service identity and permissions are required? |
| Frequency | Scheduled, event-driven or manual? |
| Freshness | When should data become visibly stale? |
| Matching | Which stable keys prevent duplicate creation? |
| Failure handling | Who receives an alert and how is work recovered? |
| Reconciliation | How are missing, changed and rejected records detected? |
| Change ownership | Who maintains the interface when either endpoint changes? |
| Commercial boundary | Which licences, middleware or services are additional? |

### Which failure tests should you run?

In an authorised test environment:

1. Remove or expire a test credential.
2. Interrupt a transfer part-way through.
3. Replay the same batch.
4. Change a source field or enumeration.
5. Supply an unexpected null or oversized attachment.
6. Remove a source record.
7. Revoke access to an evidence item.
8. Restore the interface and reconcile the result.

Require observable outcomes: alerting, controlled retry, duplicate prevention, exception handling and evidence of recovery.

For ticketing integration, decide whether ticket closure means only that engineering work is finished or that the GRC action is verified. Do not allow a status synchronisation to bypass the agreed closure reviewer.

For automated evidence, require source, collection time, covered period, completeness checks and review outcome. **Treat successful collection and successful control performance as separate acceptance questions.**

**Exit gate:** the source-system owner and operating team accept the interface, its failure behaviour and its support responsibilities.

---

# Stage 9: How do you rehearse migration and prove acceptance?

**Run a repeatable migration rehearsal with documented reconciliation before production cutover.**

Supplier investment does not remove the buyer’s responsibility to verify the result. On **29 June 2026**, Accenture and ServiceNow announced an AI-powered migration offering alongside managed security services. The announcement establishes the offering, not an independently validated duration, price or accuracy for your migration. ([newsroom.accenture.com](https://newsroom.accenture.com/news/2026/servicenow-and-accenture-launch-ai-powered-services-to-accelerate-the-shift-from-legacy-risk-platforms-to-agentic-ai))

### What is the proposed rehearsal sequence?

1. Freeze and identify the source extract.
2. Run approved cleansing and transformation steps.
3. Load reference data and parent objects in the required order.
4. Load dependent records and relationships.
5. Transfer or register evidence and history using approved methods.
6. Capture rejected rows and exceptions.
7. Reconcile objects, relationships, dates and files.
8. Run business, permission and reporting tests.
9. Correct defects and repeat with the same controlled process.
10. Rehearse the final delta and cutover sequence.

### What should reconciliation prove?

For each source population, account for:

**Extracted records = migrated records + approved archival/exclusion dispositions + unresolved exceptions.**

Where records are merged or split, use a source-to-target crosswalk rather than expecting equal counts. A successful row count is not enough.

Recommended checks include:

- Source IDs can be traced to target IDs or approved dispositions.
- Critical relationships resolve correctly.
- Owners and permissions match the approved design.
- Required dates and assessment periods retain their meaning.
- Files are retrievable and linked correctly; use checksums where files should remain unchanged.
- Historical material is labelled as historical, not recreated as a new approval.
- Reports reconcile to the agreed test population.
- Rejected records are visible and assigned.

### What should block go-live?

Set severity definitions in advance. Suggested blockers are:

- An unresolved sensitive-data permission failure.
- Missing critical records or evidence without an approved disposition.
- A mandatory workflow that cannot complete.
- Unexplained reporting discrepancies in the agreed scope.
- No workable cutover or recovery procedure.
- No accepted operating owner or support route.

Do not replace these gates with a single percentage of test cases passed. One failed critical permission test can matter more than many successful cosmetic tests.

**Exit gate:** signed migration reconciliation, business acceptance, security acceptance and documented treatment of remaining noncritical defects.

---

# Stage 10: How do you cut over without losing evidence or accountability?

**Specify which system is authoritative at every point in the transition.** Avoid an ambiguous period in which both systems can independently change the same action or assessment.

### What belongs in the cutover runbook?

Use an action list with owner, start time, dependency, expected result, evidence and escalation contact:

1. Confirm approvals and the latest successful rehearsal.
2. Communicate the change window and interim process.
3. Freeze relevant legacy changes or establish a controlled delta log.
4. Capture the final extract and backup or archive evidence.
5. Execute the approved production load.
6. Reconcile records, relationships and files.
7. Enable the approved integrations and notifications.
8. Test representative user access and critical transactions.
9. Reconcile the first production report.
10. Obtain the named go/no-go decision.
11. Open the new workflow and announce the authoritative system.
12. Begin enhanced support and defect monitoring.

### What should rollback mean?

Define the decision deadline, trigger conditions and how changes made after cutover would be handled. A rollback plan should answer:

- Which system resumes authoritative processing?
- What happens to work created in the new system?
- How are duplicate notifications or tasks prevented?
- Who reconciles the transition period?
- Who informs contributors and report users?

Keep an approved interim route for urgent findings and evidence submissions during the change window. Do not make legacy deletion part of the same irreversible decision as first go-live.

**Exit gate:** the first live workflow, integration and management report reconcile; support ownership is active; outstanding issues have explicit treatment.

---

# Stage 11: How do you run the platform after the consultants leave?

**Treat administration as a funded service with a backlog, change process and deputy—not an informal extra duty.**

The following is a proposed operating cadence. Adjust frequency to your risk, workload and service expectations.

| Cadence | Proposed activity | Accountable role |
|---|---|---|
| Daily or service-appropriate | Review failed jobs, urgent access problems and critical workflow incidents | Platform administrator |
| Weekly | Review unowned records, overdue work, support demand and defect backlog | Product owner and process owners |
| Monthly | Review licence use, data quality, evidence reuse, integration health and configuration changes | Product owner, administrator and IT |
| Quarterly or risk-based | Review privileged access, material design changes and selected portability tests | Security, platform owner and records owner |
| Before each material release | Run relevant regression, permission, integration and AI tests | Administrator and test owners |
| Before renewal decisions | Reassess fit, total cost, retained tools and exit readiness | Sponsor, finance and procurement |

### Which measures show whether adoption is real?

Prefer completed business outcomes over login counts. Suggested measures are:

- Tasks completed within the agreed workflow rather than through email workarounds.
- Evidence accepted on first review.
- Records with current owners and valid relationships.
- Actions closed with the required verification.
- Time to produce the agreed management pack.
- Manual reconciliation effort.
- Support requests by cause.
- Administrative effort per recurring process.

Keep the pre-implementation baseline and definitions so comparisons remain meaningful. Review whether reduced effort has actually been redeployed or avoided before describing a financial benefit.

### How do you preserve independence while sharing information?

Maintain separate authority over management decisions, testing conclusions and audit work. The IIA’s 2026 podcast on the refreshed Three Lines Model provides an accessible training resource on these distinctions, including assurance, advice and avoiding self-review. ([theiia.org](https://www.theiia.org/en/content/podcast/getting-started-with/2026/ep-0040/))

### What should the handover pack contain?

- Approved design and configuration register.
- Role and access matrix.
- Data dictionary and source-to-target mappings.
- Integration runbooks and support ownership.
- Migration reconciliation and archive instructions.
- Regression tests and release procedure.
- Training material and contributor guidance.
- Licence and contract inventory.
- Known defects and prioritised backlog.
- Recovery, incident and escalation procedures.
- Renewal dates and exit evidence.

**Exit gate:** the operating team accepts the service and demonstrates that it can support a normal cycle and a realistic failure.

---

# Stage 12: How do you preserve renewal leverage and a workable exit?

**Test portability while the relationship is healthy and the implementation team is still available.** Do not wait for a renewal dispute to discover what the export contains.

### What does a complete exit test include?

Require an agreed sample covering:

- Core records with stable identifiers.
- Parent-child and many-to-many relationships.
- Attachments and evidence metadata.
- Relevant comments, approvals and history.
- Definitions of statuses, scores and enumerations.
- Configuration and workflow documentation.
- Content-licensing restrictions.
- A readable archive and retrieval procedure.

Have a buyer-controlled analyst reconstruct selected records without relying on the live platform interface.

Workiva’s 2026 Files API documentation illustrates the need to specify export options: folder and Workiva-file exports include explicit choices for attachments, comments and other metadata, and a `removeGRCLinks` option removes connections to the original GRC database while preserving textual or value representations. This is documentation about particular export operations—not proof of complete GRC database portability. Test the precise export route you intend to use. ([developers.workiva.com](https://developers.workiva.com/2026-01-01/files.html))

### How should you work backwards from renewal?

Record the actual contract’s notice deadline first. Then work backwards through:

1. Executive decision and approval time.
2. Competitive evaluation or incumbent remediation.
3. Security and contractual review.
4. Migration preparation and build.
5. Testing and safe cutover windows.
6. Required overlap and archive validation.

Use the longer dependency path, not a generic “start 90 days before renewal” rule. If the notice date arrives before a safe alternative can be ready, evaluate a negotiated bridge or bounded renewal rather than pretending switching is immediately feasible.

For banking relationships, the interagency guidance supports addressing transition periods, data return/destruction and associated costs contractually. Your actual rights depend on the executed agreement and applicable law. ([occ.gov](https://www.occ.gov/news-issuances/federal-register/2023/88fr37920.pdf))

**Exit gate:** the organisation knows when it must decide, what it can export, what remains dependent on the supplier and how a transition would be funded.

---

# Which pitfalls should stop or change the programme?

Use this proposed exception table at each steering meeting.

| Warning sign | Recommended response |
|---|---|
| Sponsor wants a platform but cannot name the first outcome | Return to the charter before procurement |
| Every stakeholder request is mandatory | Resolve priorities and publish exclusions |
| Migration is described only as a CSV upload | Require evidence, history, relationship and reconciliation scope |
| Demonstrations use only administrator accounts | Repeat with contributor, reviewer, restricted and integration identities |
| A connector is shown without failure handling | Require an interface specification and recovery test |
| Administration is assumed to be negligible | Run the buyer-administrator task test and revise staffing |
| A mandatory feature is only on a roadmap | Treat it as unproven; change the contract, scope or shortlist |
| The quote lacks licence-action definitions | Obtain written clarification before TCO comparison |
| AI appears to save drafting time but increases review | Measure end-to-end effort and keep the feature optional |
| Exit evidence consists only of a report download | Test reconstruction of relationships, attachments and relevant history |

---

# What should you do in the first 30 days?

**Produce decision evidence, not a long supplier list.** This proposed first-month plan prepares the organisation to buy—or to decide that buying is premature.

| Period | Work | Required output |
|---|---|---|
| Days 1–5 | Appoint sponsor and programme owner; record trigger, dates and alternatives | Decision charter and stakeholder map |
| Days 6–10 | Walk through one real process with owners and contributors | Current-state process and measurable baseline |
| Days 11–15 | Agree release-one scope, decision rights and applicability questions | Scope charter and unresolved-decision log |
| Days 16–20 | Inventory source data and test a difficult sample | Data-readiness findings and remediation backlog |
| Days 21–25 | Draft requirements, mandatory gates and demo cases | Evaluation workbook and scenario pack |
| Days 26–30 | Build a task-based resource plan and initial TCO; challenge the route | Sponsor decision to repair, configure, buy, build or pause |

By day 30, you should be able to say:

> We know the first workflow, its owners, the records it needs, the decisions we have not resolved, the evidence suppliers must provide and the internal capacity we must fund.

That is a stronger procurement starting point than knowing which demonstration was most impressive.

---

# What documents should you have at the end?

The complete buyer-owned file should contain:

- [ ] Decision charter, alternatives and business-case baseline.
- [ ] Scope charter and regulatory-applicability register.
- [ ] Responsibility map and approved resource plan.
- [ ] Data inventory, dictionary, remediation backlog and historical-retention decisions.
- [ ] Requirements workbook, weighted scorecard and mandatory gates.
- [ ] RFP responses and normalised commercial comparison.
- [ ] Demonstration and proof-of-concept evidence.
- [ ] Security and privacy diligence with resolved exceptions.
- [ ] Three-year TCO, sensitivity analysis and funding approval.
- [ ] Executed agreement, statement of work and acceptance schedule.
- [ ] Design baseline and configuration register.
- [ ] Integration specifications and runbooks.
- [ ] Migration scripts or procedures, crosswalks and reconciliations.
- [ ] UAT, permission and regression-test results.
- [ ] Cutover, rollback and communications plans.
- [ ] Training, support and operating handover.
- [ ] Renewal calendar and tested exit pack.

**Final recommendation:** retain ownership of scope, data, acceptance and operation even where you buy specialist help. Do not sign until the organisation can explain both how it will get onto the platform and how it will maintain—or leave—it.

---

# Sources

The sources below support factual statements. The proposed plans, templates and financial scenario are this desk’s analytical work. Supplier documentation should be reconfirmed against the edition, deployment and contract being purchased.

### Implementation and operating model

1. KPMG — *Implement GRC technology the right way*: `https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf`
2. KPMG — *Pathway to technology alignment*: `https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/pathway-technology-alignment.pdf`
3. The IIA — 2026 Statements of Position and publication dates: `https://www.theiia.org/en/resources/statements-of-position`
4. The IIA — *Three Lines Model: Assurance and Advice in Support of Effective Governance*: `https://www.theiia.org/globalassets/site/resources/statements-of-position/tlm_assurance_advice_support_effective_gov_en.pdf`
5. The IIA — podcast and transcript on the refreshed model: `https://www.theiia.org/en/content/podcast/getting-started-with/2026/ep-0040/`
6. First Horizon — Senior GRC Administrator posting, 9 April 2026; indexed posting used as role evidence, not a staffing benchmark: `https://recruiting.ultipro.com/FIR1007FTN/JobBoard/c005ef3e-175a-49c4-ba29-9f431f673944/OpportunityDetail?opportunityId=3d3259bf-0bb5-474b-8eb4-639fe8f63a6b`
7. LogicGate — implementation packages and services scope: `https://www.logicgate.ai/services-description/`
8. ServiceNow — Risk and Compliance implementation-specialist blueprint: `https://learning.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0011655`
9. ServiceNow — Risk Speed Learning and linked video tutorials: `https://www.servicenow.com/community/grc-articles/risk-speed-learning-hands-on-how-to-video-tutorials-to-configure/ta-p/3462795`
10. Learning Tree — ServiceNow GRC/IRM implementation training and published price: `https://www.learningtree.com/courses/servicenow-grc-irm-implementation-training/`

### US regulatory and framework references

11. NIST — CSF 2.0 Organisational Profiles and template: `https://www.nist.gov/cyberframework/profiles`
12. OCC — *Third-Party Relationships: A Guide for Community Banks*, 3 May 2024: `https://www.occ.gov/news-issuances/bulletins/2024/bulletin-2024-11.html`
13. OCC/Federal Register — 2023 Interagency Guidance on Third-Party Relationships: `https://www.occ.gov/news-issuances/federal-register/2023/88fr37920.pdf`
14. FTC — Safeguards Rule business guidance: `https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know`
15. HHS — HIPAA and cloud computing guidance: `https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html`
16. HHS — Summary of the HIPAA Security Rule: `https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html`
17. SEC — Staff Statement on Management’s Report on Internal Control Over Financial Reporting: `https://www.sec.gov/info/accountants/stafficreporting.htm`
18. NYDFS — Cybersecurity Resource Center: `https://www.dfs.ny.gov/cybersecurity`
19. NYDFS — implementation timeline for covered entities: `https://www.dfs.ny.gov/industry_guidance/cybersecurity/implementation_timeline_covered_entities`
20. NIST — Generative AI Profile, NIST AI 600-1: `https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf`

### Product, pricing, procurement and migration evidence

21. IBM — OpenPages pricing and deployment caveats: `https://www.ibm.com/products/openpages/pricing`
22. IBM — OpenPages 9.1 FastMap overview; indexed documentation used where direct retrieval was restricted: `https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview`
23. IBM — OpenPages 9.1 Data Export and permission warning; indexed documentation used where direct retrieval was restricted: `https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications`
24. ServiceNow — Australia release common controls in Risk Management: `https://www.servicenow.com/docs/r/governance-risk-compliance/grc-risk-management-workspace/shared-common-controls-in-risk-management.html`
25. Archer — IT Security Risk Management Integration Guide: `https://help.archerirm.cloud/archersolutions/en-us/Content/ArcherSolutions/itsrm_integration_guide.htm`
26. Workiva — 2026 Files API export options: `https://developers.workiva.com/2026-01-01/files.html`
27. LogicGate — published pricing structure: `https://www.logicgate.ai/platform/pricing/`
28. Optro — AuditBoard rebrand announcement, 9 March 2026: `https://optro.ai/blog/meet-optro-auditboard-unveils-new-identity-as-ai-transforms-grc`
29. EPB — public procurement listing, including 2026 Audit, Risk and Compliance Solution/GRC requirement: `https://business.epb.com/competitive-sealed-bids-request-for-proposals/`
30. Accenture — joint ServiceNow migration and managed-services announcement, 29 June 2026: `https://newsroom.accenture.com/news/2026/servicenow-and-accenture-launch-ai-powered-services-to-accelerate-the-shift-from-legacy-risk-platforms-to-agentic-ai`