# Scorecard

Controlspan Research Desk · Last updated 28 October 2026

# How should you evaluate an enterprise GRC platform?

**Evaluate the proposed operating solution—not the software catalogue.** Use mandatory gates to exclude unacceptable risks, then score twelve weighted criteria covering workflow fit, migration, implementation, integrations, security, adoption, administration, reporting, ownership cost and exit.

This scorecard gives **60 of its 100 points** to migration, delivery, integrations, adoption, administration, three-year cost and exit. That allocation is deliberate: the desk’s recommendation is to prioritise what the organisation can implement and operate over optional breadth.

The unit being evaluated is:

> **Specified software edition and deployment + implementation partner + first-release scope + buyer resources + commercial terms.**

A different partner, implementation scope or hosting arrangement is a different proposal and should receive a separate assessment.

The lifecycle approach has a regulatory foundation. US banking agencies’ third-party guidance covers planning, selection, contracting, ongoing monitoring and termination—not selection alone. It also makes clear that using a third party does not remove a banking organisation’s responsibility for its activities. ([federalreserve.gov](https://www.federalreserve.gov/newsevents/pressreleases/bcreg20230606a.htm?trk=public_post_comment-text&utm_source=openai))

**Methodology notice:** The weights, scoring anchors, evidence caps, test scenarios and decision thresholds below are this desk’s proposed evaluation method. They are not regulatory requirements, industry benchmarks or statistically validated predictors of implementation success. No supplier has been tested or ranked in this document.

### What should the final decision pack contain?

Produce five outputs rather than a single league table:

1. **Mandatory-gate register:** pass, hold or fail, with accountable sign-off.
2. **Evidence-adjusted score:** a weighted result out of 100.
3. **Evidence coverage:** how much of the evaluation has adequate supporting proof.
4. **Three-year ownership model:** comparable USD costs, assumptions and unresolved exposures.
5. **Contract and implementation conditions:** what must be resolved, delivered or retested.

A high score must never compensate for a failed permission boundary, an unaffordable commitment or an essential workflow that does not work.

---

# 1. What must be fixed before suppliers are scored?

**Agree the first useful release, its users and its acceptance conditions before demonstrations begin.** Give every supplier the same scope and distinguish mandatory requirements from desirable capabilities.

NIST’s cybersecurity supply-chain quick-start guide explicitly addresses defining and communicating supplier requirements. Use that principle to make requirements an input to procurement, rather than something reconstructed from sales presentations. ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/1305/final))

### Complete this scope charter

| Decision | Required entry |
|---|---|
| Buying trigger | Finding, renewal, acquisition, spreadsheet replacement or another defined problem |
| First-release outcome | For example, accountable control testing and remediation across named business units |
| Essential workflows | Specific processes that must work at launch; identify their business owners |
| Explicit exclusions | Future modules, entities, integrations and AI uses that are not being purchased now |
| Users and permissions | Administrators, risk practitioners, control owners, executives, auditors and external contributors |
| Data footprint | Object counts, attachments, history, sensitive classifications and source repositories |
| Technical dependencies | Identity, ticketing, evidence sources, reporting tools and retained specialist systems |
| Operational constraints | Internal capacity, required support hours, hosting constraints and recovery objectives |
| Commercial envelope | Preferred three-year budget, maximum approved exposure and growth assumptions |
| Acceptance authority | Named people authorised to accept workflow, data, security and commercial evidence |

Write requirements as observable outcomes. Replace “supports risk aggregation” with “reproduces the approved business-unit and group-level risk report, including the treatment of disputed assessments and shared exposures”.

Record each supplier’s edition, release, enabled modules, hosting arrangement, partner and demonstration configuration. Label delivery mechanisms as **standard**, **supported configuration**, **custom development**, **third-party dependency** or **roadmap**. Do not treat those categories as equivalent.

Include a **retain-and-repair incumbent option** where credible. Evaluate it against the same future outcomes and include its future operating, remediation and retained-tool costs. Do not give it free credit merely because it is already installed.

---

# 2. Which requirements should be mandatory gates?

**Use gates for conditions the organisation cannot sensibly trade away.** Apply the gates below to the first-release scope and approved risk appetite, not indiscriminately to every possible use case.

- **Pass:** the agreed condition is evidenced and accepted.
- **Hold:** evidence, remediation or contractual agreement remains outstanding.
- **Fail:** the proposal cannot meet the condition within the accepted scope and constraints.

A hold is not a pass. A failed proposal may be reconsidered after a documented change and retest; do not waive the failure by increasing its weighted score.

| Gate | Required evidence for a pass | Accountable sign-off |
|---|---|---|
| **G1. Security and permission boundaries** | Approved access design; demonstrated role restrictions across records, attachments, search, reporting, exports and enabled AI; acceptable identity and privileged-access arrangements | CISO / security architecture |
| **G2. Supplier assurance and applicable contractual duties** | Risk-based supplier review; acceptable assurance evidence, recovery arrangements, data-processing terms, subprocessors and applicable sector agreements | Third-party risk, legal and privacy |
| **G3. Essential workflows and assurance separation** | Every designated launch-critical workflow passes; required approval and challenge rights cannot be bypassed through ordinary user actions | Process owners; internal audit where relevant |
| **G4. Information preservation and retrieval** | Agreed records, evidence, relationships and required history survive migration or remain in an approved archive; representative retrieval and export tests pass | Data owner, records management and audit |
| **G5. Deliverability and operating capacity** | Named buyer and supplier owners; credible dependencies and acceptance plan; funded administration and support after handover | Sponsor and programme lead |
| **G6. Affordable, defined commercial scope** | Required modules, users, interfaces and services are priced; base and downside exposure are within approved limits; no material unpriced dependency | Finance and procurement |
| **G7. Safe AI deployment, if enabled** | Approved data handling and model arrangements; permission tests pass; consequential actions require agreed human authority; disablement works | CISO and AI/model-risk owner |

For G2, do not equate the existence of an assurance report with adequate assurance. Banking guidance specifically calls for considering whether the scope and results of SOC reports or other assessments are relevant to the activity being outsourced. ([federalreserve.gov](https://www.federalreserve.gov/supervisionreg/srletters/SR2304.pdf))

### How should sector requirements change the gates?

**Establish applicability with the buyer’s legal, compliance and assurance specialists.** The following are prompts, not a complete regulatory mapping.

| Buyer context | Source-backed consideration | Proposed evaluation consequence |
|---|---|---|
| US banking organisation | The agencies’ community-bank guide addresses resources, transition capability, termination costs and data inventories. ([federalreserve.gov](https://www.federalreserve.gov/publications/files/third-party-risk-management-guide-20240503.pdf)) | Test the GRC supplier as a third party, including continuity and exit—not only its third-party-risk module |
| HIPAA-regulated organisation placing ePHI in the service | HHS states that a cloud provider creating, receiving, maintaining or transmitting ePHI on the organisation’s behalf is a business associate, including when it cannot decrypt the information. A compliant BAA is required in that situation. ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html)) | Determine whether ePHI is actually needed; if it is, validate the applicable BAA and service scope before uploading it |
| NYDFS-covered entity | NYDFS’s 21 October 2025 guidance addresses third-party selection, contracting, monitoring and termination; it clarifies existing requirements and recommends practices rather than imposing new obligations. ([dfs.ny.gov](https://www.dfs.ny.gov/industry-guidance/industry-letters/il20251021-guidance-managing-risks-third-party)) | Separate applicable requirements from recommended contract protections and document any accepted gaps |
| Internal-audit-led programme | The IIA’s Standard 7.1 addresses organisational independence and safeguards against impairment. ([theiia.org](https://www.theiia.org/globalassets/site/standards/globalinternalauditstandards_2024january9.pdf)) | Have internal audit approve the proposed division of management, assurance and administrator powers |

Do not turn “US-focused” into an automatic claim that every buyer is legally required to use US-only hosting. HHS’s cloud guidance, for example, discusses overseas processing as a risk-analysis consideration rather than imposing a blanket domestic-hosting requirement. ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html))

---

# 3. What are the weighted enterprise GRC evaluation criteria?

**Use these weights as the default for a phased enterprise deployment.** The anchors describe the proposed solution and operating plan, not a supplier’s reputation.

The table supplies **1, 3 and 5 anchors** for every criterion. The following section explains zero scores, intermediate scores and evidence caps.

| ID and criterion | Weight | 1 — Weak | 3 — Acceptable for the agreed scope | 5 — Strong |
|---|---:|---|---|---|
| **C1. Operating-model and workflow fit** | **15%** | Generic registers; ownership and approval decisions remain outside the system | Named owners, approvals, exceptions and essential risk/control/action relationships work | Buyer reproduces end-to-end workflows, disputed decisions and entity-level roll-ups without unapproved workarounds |
| **C2. Specialist depth and assurance separation** | **8%** | A general workflow is presented as a substitute for essential audit, controls, IT-risk or third-party-risk work | The chosen specialist use case works, including required reviewer and management separation | Specialist users complete realistic testing, challenge, review and closure scenarios with defensible evidence |
| **C3. Migration, history and data quality** | **12%** | “Upload a CSV” with no field, relationship or historical-retention design | Approved mapping, cleansing ownership and representative reconciliation; history/archive treatment is explicit | Repeatable migration rehearsal reconciles records, attachments, relationships and retained provenance, with rollback and exception handling |
| **C4. Implementation plan and delivery capacity** | **12%** | Generic schedule, unnamed team and unspecified buyer effort | Named delivery roles, resource assumptions, dependencies, acceptance milestones and change control | Delivery commitments and buyer capacity are corroborated; critical dependencies and cutover are rehearsed; comparable references are checked |
| **C5. Integrations and evidence reliability** | **10%** | Connector logos or one successful data transfer | Required objects, directions, identity, mappings and error ownership are demonstrated | Buyer verifies failure detection, retry, duplicate prevention, reconciliation and recovery at representative load |
| **C6. Security, privacy and resilience** | **10%** | Badge-led assurance; unclear access, recovery or processing arrangements | Approved architecture and supplier review; scoped access tests and recovery evidence meet buyer requirements | Permission boundaries, privileged actions and recovery arrangements withstand buyer-defined adverse scenarios; residual risks are explicit |
| **C7. Business-user adoption** | **8%** | Specialists navigate everything; contributors need continual assistance | Representative occasional users complete assigned tasks within buyer-set limits | Unassisted users handle reassignment, rejection and escalation; measured friction and support needs fit the operating plan |
| **C8. Administration and changeability** | **5%** | Routine changes depend on external specialists without a costed service model | Buyer administrators make agreed routine changes using documentation and controlled environments | Administrators repeat changes, regression checks, deployment and rollback; support and upgrade responsibilities are clear |
| **C9. Reporting and decision traceability** | **5%** | Attractive dashboards with unclear definitions or off-system reconciliation | Required reports reconcile to underlying records, owners and evidence | Buyer reproduces historical reporting, exclusions and calculation logic and traces decisions without unexplained manual adjustments |
| **C10. Three-year TCO and commercial terms** | **10%** | Subscription-only comparison, unpriced dependencies or unclear expansion costs | Comparable USD cost model fits the approved ceiling; material inclusions, assumptions and terms are agreed | Base cost fits the preferred budget, downside exposure is acceptable, and growth, renewal and change-cost mechanisms are defined |
| **C11. Exit and supplier continuity** | **3%** | “Your data is yours” without usable extraction or transition arrangements | Representative export is usable; retention, assistance, access and charges are agreed | Buyer reconstructs selected records outside the platform; transition and disruption contingencies have owners, resources and tested steps |
| **C12. AI feature assurance, if in scope** | **2%** | Fluent output without traceable evidence, permission testing or accountable approval | Approved use cases have source checks, permission controls, human review and disablement | Buyer-held-out tests demonstrate acceptable quality and review effort, including conflicting evidence and adversarial-document cases |
| **Total** | **100%** | | | |

### Who should own each score?

Assign one accountable evaluator per criterion, supported by the relevant specialists:

- **C1:** CRO or first-workflow process owner.
- **C2:** audit, compliance, security or third-party-risk leader for the selected specialist use case.
- **C3–C4:** programme lead, supported by data owners and delivery assurance.
- **C5–C6:** enterprise architect and CISO respectively.
- **C7:** business-user representative, not only the implementation team.
- **C8:** the person expected to administer the production platform.
- **C9:** reporting owner, with audit challenge where appropriate.
- **C10:** finance and procurement.
- **C11:** procurement, records management and architecture.
- **C12:** AI-risk owner with the intended business users.

Record disagreements. Do not average away a security or assurance objection by counting more favourable votes from other functions.

---

# 4. How do you calculate scores without rewarding unsupported claims?

**Score suitability and evidence separately, then use the lower result.** A convincing promise should not receive the same credit as a buyer-reproduced outcome.

### Step A: Assign a suitability score

| Score | Meaning |
|---:|---|
| **0** | Observed failure or confirmed inability to meet the requirement in the proposed scope |
| **1** | Meets only the weak anchor; material workarounds or unresolved dependencies |
| **2** | Better than the weak anchor but does not yet meet all conditions of the acceptable anchor |
| **3** | Meets every condition of the acceptable anchor |
| **4** | Meets the acceptable anchor and most strong-anchor conditions; remaining gaps are explicit |
| **5** | Meets every strong-anchor condition relevant to the agreed scope |
| **U** | Unknown or not evaluated; capability has not been established |

Use **U**, not “unsupported capability”, when something was not demonstrated. For conservative calculation, U earns zero points until resolved, but it remains visibly different from an observed failure.

Roadmap functionality receives no first-release capability credit. A promise to build something is evidence about a delivery dependency, not proof that the required capability exists.

### Step B: Apply the evidence cap

| Evidence level | Maximum earned score | What qualifies |
|---|---:|---|
| **E0: no usable evidence** | **0** | No evidence, or evidence unrelated to the offered scope |
| **E1: assertion** | **1** | Sales statement, generic marketing material or an unverified response |
| **E2: documented capability** | **2** | Relevant technical documentation or a detailed design, without adequate validation of the proposed use |
| **E3: observed or substantively reviewed** | **3** | Witnessed buyer scenario; or reconciled commercial, security or delivery evidence appropriate to a documentary criterion |
| **E4: buyer-validated** | **4** | Buyer repeats the task or independently validates the relevant artefacts and dependencies |
| **E5: operationally validated** | **5** | E4 plus applicable exception, scale, recovery or lifecycle checks; contractual dependencies are in execution-ready agreed documents |

**Documentary criteria need equivalent proof, not artificial demonstrations.** For C10, for example, E4 could mean finance has independently reconciled quantities and charges to the quote and statement of work. E5 additionally requires validated downside scenarios and agreed contractual treatment of material exposures. For C4, a signed plan alone does not establish that named people are available or that a migration dependency is achievable.

Apply the cap to the whole criterion only when the evidence covers its material requirements. One working integration does not validate every critical integration in scope.

### Step C: Calculate the result

For each criterion:

`Earned score = MIN(suitability score, evidence cap)`

`Weighted points = criterion weight × earned score ÷ 5`

`Total score = SUM(weighted points)`

Store weights as numbers totalling 100. With weights in `B2:B13` and earned scores in `C2:C13`, the spreadsheet formula is:

`=SUMPRODUCT(B2:B13,C2:C13)/5`

Calculate evidence coverage separately:

`Evidence coverage = SUM(weights of criteria with adequate E3–E5 evidence)`

Coverage measures the share of weighted scope with adequate proof. It is **not a statistical confidence level**, and high coverage does not imply high quality: a thoroughly tested failure has strong evidence but a low suitability score.

### What happens to missing or inapplicable requirements?

- **Missing evidence:** retain the weight and record U. Never shrink the denominator for one supplier.
- **Genuinely out-of-scope requirement:** remove it consistently for every option before scoring and reallocate its weight.
- **AI excluded:** the default adjustment is C12 from 2% to 0% and C8 from 5% to 7%. Confirm that excluded AI pathways are disabled or otherwise approved under C6.
- **Critical failed subtest:** apply the relevant gate. Do not let successful minor tasks compensate for it.

---

# 5. What should every shortlisted supplier demonstrate?

**Give every supplier the same synthetic business scenario and require buyer participation.** Use supplier demonstrations to establish basic fit, then use a controlled sandbox or equivalent proof exercise to validate repeatability and exceptions.

Do not upload production credentials, patient information or identifiable findings merely to make a demonstration realistic.

### A proposed enterprise GRC demonstration script

| Test | Buyer instruction | Observable acceptance evidence | Main criteria |
|---|---|---|---|
| **T1. Overdue remediation** | Make an action overdue, reassign its owner, request an extension and reject closure | Original and revised dates remain distinguishable; escalation, approval and reopening follow the agreed process | C1, C7, C9 |
| **T2. Disputed risk assessment** | Have a business owner challenge a risk score and a second-line reviewer disagree | Both positions, rationale, decision authority and approved reporting treatment remain traceable | C1, C2, C9 |
| **T3. Evidence reuse with restrictions** | Reuse one evidence item for multiple controls while restricting a sensitive attachment | Permitted users can reuse it; restricted users cannot retrieve it through search, reports, links, exports or enabled AI | C2, C6 |
| **T4. Dirty migration** | Load synthetic duplicates, missing owners, orphan links, historical evidence and attachment versions | Exceptions are reported; approved transformations are reproducible; retained records and relationships reconcile | C3 |
| **T5. Failed integration** | In an authorised test environment, interrupt a connector, expire its credential and replay a message | Alerting, responsible ownership, recovery, duplicate handling and reconciliation are visible | C5 |
| **T6. Occasional-user task** | Ask representative contributors to submit evidence, respond to rejection and delegate during absence | Completion, elapsed time, mistakes and assistance are measured against pre-agreed limits | C7 |
| **T7. Administrator change** | Have the buyer’s administrator add a field, alter an approval and change a report | Change, testing, deployment and rollback are completed with the intended support model | C8 |
| **T8. Reperform a report** | Rebuild one committee report from underlying records and reproduce an earlier reporting period | Population, exclusions, calculations and evidence links reconcile | C9 |
| **T9. Exit extraction** | Export a selected record set, attachments, relationships and agreed history; inspect it outside the platform | Stable identifiers, readable files, relationship mapping and a manifest permit reconstruction | C3, C11 |
| **T10. AI challenge, if enabled** | Provide conflicting sources, an inaccessible document, an unanswerable question and misleading instructions inside evidence | Sources and uncertainty are visible; access remains enforced; document content does not authorise actions | C6, C12 |

For every test retain: test ID, exact configuration, performer, input set, expected outcome, observed result, evidence location, defect, proposed remedy and retest date.

**Do not confuse organisational independence with a permission setting.** The IIA’s independence requirements concern organisational positioning and safeguards, not merely software roles. Our proposed software test is to verify that the agreed governance model is not undermined by record editing, approval or administrative powers. ([theiia.org](https://www.theiia.org/globalassets/site/standards/globalinternalauditstandards_2024january9.pdf))

---

# 6. Where should evaluators probe beyond the standard demonstration?

### Can migration preserve the meaning of historical evidence?

**Require a preservation design, not just a successful import count.** Separate current operational data, historical versions, original provenance and records retained in a searchable archive.

A concrete documentation example shows why this matters: IBM’s OpenPages 9.1.x FastMap documentation states that FastMap cannot import attachments or signatures and cannot preserve original system creation dates through that process. These are limitations of the specified import mechanism—not proof that OpenPages has no alternative migration route. ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview&utm_source=openai))

Require the migration proposal to identify:

- The supported route for each object, attachment and history type.
- Source and target identifiers, transformation rules and relationship crosswalks.
- Whether original timestamps remain as source metadata, native history or archived evidence.
- Record, attachment and relationship reconciliation separately.
- Treatment of rejected records and duplicates.
- Freeze, delta-load, rollback and archive-access arrangements.

Do not silently represent imported source history as events generated natively by the new platform. Make provenance visible and have the records owner approve the treatment.

### What does a connector actually include?

**Score the integration contract and operating behaviour, not the connector name.** Require an interface schedule covering objects, direction, frequency, authentication, permitted actions, volumes, failure handling and maintenance ownership.

LogicGate’s published API getting-started page states that API access requires an add-on and discusses pagination and a recommended request rate. That is a useful prompt to verify commercial entitlement and throughput in the buyer’s actual offer; it is not a current quotation or a measured performance result. ([logicgate.ai](https://www.logicgate.ai/developer/risk-cloud-api-getting-started/))

For each critical interface, distinguish:

1. **Source validity:** does the incoming information represent the intended population and period?
2. **Transport reliability:** was it transferred completely and once, with detectable failures?
3. **GRC interpretation:** did the platform create the right evidence, finding or action?
4. **Operational ownership:** who notices, diagnoses and repairs a failure?

Include source-system and middleware charges in the commercial schedule where applicable. Make the supplier identify whether changes to the source API are covered by support or require paid engineering.

### Can occasional contributors do their work under the quoted licence?

**Map actions to entitlements, not only people to job titles.** A contributor test should use the proposed licence and permission combination.

For example, ServiceNow’s IRM entitlement document effective 9 May 2024 differentiates Operator and Lite Operator rights, including limits around internal-audit data. Treat that dated document as evidence that contractual distinctions matter—not as a substitute for the entitlement schedule governing a 2026 purchase. ([servicenow.com](https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/other-document/entitlements/PROD14209.pdf))

Ask the supplier to price and validate these actions separately: submitting evidence, approving an assessment, closing an issue, viewing reports, administering workflows and participating as an external auditor.

### Who operates the platform after the consultants leave?

**Require a workload model and a practical handover test.** Specify responsibility for access, configuration, data quality, integrations, releases, reporting, training and incident escalation.

A First Horizon employer posting dated 9 April 2026 for a Senior GRC Administrator explicitly includes configuration governance, data integrity, release control, integration validation and production stability. This is a concrete example of operational responsibilities—not evidence of a universal staffing requirement or salary benchmark. ([recruiting.ultipro.com](https://recruiting.ultipro.com/FIR1007FTN/JobBoard/c005ef3e-175a-49c4-ba29-9f431f673944/OpportunityDetail?opportunityId=3d3259bf-0bb5-474b-8eb4-639fe8f63a6b&utm_source=openai))

For the buyer’s operating model, estimate task volumes and effort rather than adopting an unsupported “one administrator” assumption. Record which responsibilities are internal, managed-service or supplier obligations and price them accordingly.

### How should AI features be evaluated?

**Make AI a small, separately governed part of the score unless it is genuinely central to the approved use case.** Do not award extra points merely for the number of AI-labelled features.

In its May 2026 GRC market commentary, Verdantix described expanding AI capabilities and supplier repositioning as potential sources of buyer confusion. NIST’s Generative AI Profile identifies risks including fabricated information, privacy leakage and problematic human reliance on AI output. ([verdantix.com](https://www.verdantix.com/insights/blog/riding-the-wave-of-capability-and-strategy-changes-in-the-grc-industry))

Use a buyer-held-out evaluation set and measure:

- Whether cited evidence actually supports each material conclusion.
- Whether inaccessible or deleted evidence can influence an answer.
- Handling of contradictory, obsolete and missing information.
- Human review and correction time, including rejected outputs.
- Ability to prevent or reverse unauthorised workflow changes.
- Data retention, training use, subprocessors and disablement.

Set acceptance thresholds before testing. A clean sample is not proof that future outputs will always be accurate. Retain input versions, source versions, relevant configuration and outputs; do not demand identical wording as the sole definition of reproducibility.

For high-consequence decisions, retain an accountable human approval step. This is the desk’s proposed control response to the confabulation and human–AI interaction risks described by NIST. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf))

---

# 7. How should enterprise GRC software pricing and three-year TCO be scored?

**Normalise the delivered scope before comparing price.** C10 should reward an affordable, transparent commitment—not merely the lowest subscription quotation.

Use the same user actions, entities, modules, data volumes, environments, integration scope and rollout assumptions across proposals. If one option needs a retained specialist tool, include its future cost rather than pretending consolidation is complete.

### Three-year GRC total cost of ownership checklist

| Cost category | Items to establish | Evidence to request |
|---|---|---|
| Software | Modules, licence categories, entities, environments, storage and volume commitments | Itemised order form and governing entitlement schedule |
| Integration and content | API access, connectors, middleware, regulatory content and source-system costs | Interface-by-interface inclusion schedule |
| External delivery | Discovery, design, configuration, migration, testing, training and programme management | Statement of work with assumptions, exclusions and change rates |
| Internal implementation | Process decisions, cleansing, architecture, security review, testing and training | Buyer-approved hours and loaded rates |
| Ongoing operations | Administration, integration support, releases, assurance, reporting and managed services | Operating model and support responsibilities |
| Transition | Legacy overlap, archive access, extraction and temporary support | Incumbent and replacement contract assumptions |
| Commercial change | Renewal increases, minimum commitments, expansion pricing and overage treatment | Agreed pricing mechanisms and notice provisions |
| Exit scenario | Export, assistance, reconstruction, overlap and contractual termination charges | Separately priced transition scenario |

The banking agencies’ guidance discusses clear cost schedules, conditions for cost changes and potentially burdensome upfront or termination fees. Those are useful contracting prompts; the model above is the desk’s proposed way to organise the buyer’s comparison. ([federalreserve.gov](https://www.federalreserve.gov/supervisionreg/srletters/SR2304.pdf))

### Use a transparent calculation

`Three-year economic TCO = external cash costs over 36 months + internal implementation labour + internal operating labour`

Show external cash spending and internal labour separately. Count each cost once. For example, do not add an administrator’s full allocated cost and also charge the same hours through individual tasks.

Include planned dual-running. Keep an optional exit at the end of year three separate unless the buyer actually intends or is contractually committed to exit then. Keep potential benefits separate from costs; released staff time is not automatically a payroll saving.

### Illustrative calculation—not a market price benchmark

| Assumed item | Calculation | Three-year cost |
|---|---|---:|
| Subscription | $150,000 × 3 years | $450,000 |
| External implementation | One-off assumption | $150,000 |
| Internal implementation | 800 hours × $75 | $60,000 |
| Ongoing administration | 60 hours/month × 36 months × $75 | $162,000 |
| Legacy overlap | Assumed total | $30,000 |
| **Illustrative economic TCO** | | **$852,000** |

This example assumes no subscription increases or additional connector, support or content charges. It is incomplete for a real purchase until those assumptions are confirmed.

**An unknown charge remains unknown, not zero.** Show a supplier-confirmed amount, a buyer assumption with an explicit range, or an unresolved item.

Build a downside case from buyer-selected events: additional contributors, delayed cutover, a required custom interface, more administration or an added entity. Do not present the downside case as a forecast probability unless the buyer has evidence for that probability.

For C10, agree the preferred budget and maximum acceptable downside exposure before opening final bids. A fully priced proposal within the ceiling can earn 3; a proposal needs the stronger budget, exposure and contractual conditions in the matrix to earn 5.

---

# 8. How should weights change for different buying situations?

**Change weights before scored demonstrations and apply the same changes to every option.** Change the test content as well: a higher audit weight is meaningless if the supplier is still shown only a risk-register scenario.

These are proposed alternatives to the default, not sector benchmarks:

| Buying situation | Increase | Offset | Result |
|---|---|---|---|
| **SOX or internal-audit-led selection** | C2 +4 points; C9 +2 | C1 −3; C5 −3 | More emphasis on specialist assurance and reporting; total remains 100 |
| **IT-risk and continuous-evidence programme** | C5 +5; C6 +2 | C1 −4; C2 −3 | More emphasis on integration behaviour and security; total remains 100 |
| **Complex incumbent replacement** | C3 +3; C11 +3 | C1 −4; C2 −2 | More emphasis on historical fidelity and portability; total remains 100 |
| **AI excluded from scope** | C8 +2 | C12 −2 | No AI feature premium; total remains 100 |

Treat the first three rows as alternative profiles rather than automatically stacking them. A healthcare or banking label should first trigger applicability and gate discussions, not mechanically generate an arbitrary weight increase.

### How do you test whether the ranking is fragile?

Recalculate under the most plausible alternative profile and the downside cost case. Also lower any disputed criterion by one score point and observe the effect.

A one-point score change in a 15%-weighted criterion changes the total by **3 points**. If finalists are separated by less than that, one disputed judgement may explain the result. Report that sensitivity instead of presenting the leading score as decisive.

---

# 9. What does a completed scorecard look like?

**The following is a synthetic illustration, not a comparison of real suppliers.** Both proposals are assessed against the default weights; all scores shown are after evidence caps.

| Criterion | Weight | Proposal A | Proposal B |
|---|---:|---:|---:|
| C1. Workflow fit | 15 | 5 | 4 |
| C2. Specialist depth | 8 | 4 | 4 |
| C3. Migration | 12 | 2 | 5 |
| C4. Implementation | 12 | 2 | 4 |
| C5. Integrations | 10 | 4 | 4 |
| C6. Security | 10 | 4 | 4 |
| C7. Adoption | 8 | 4 | 4 |
| C8. Administration | 5 | 2 | 4 |
| C9. Reporting | 5 | 5 | 4 |
| C10. TCO and terms | 10 | 2 | 4 |
| C11. Exit | 3 | 1 | 4 |
| C12. AI assurance | 2 | 4 | 3 |
| **Weighted total** | **100** | **66.6** | **82.0** |
| **Evidence coverage** | | **58%** | **100%** |
| **Gate status** | | **Hold** | **Pass** |

In this example, A has stronger demonstrated workflow and reporting features, but C3, C4, C8, C10 and C11 remain below E3 evidence quality. Those rows account for 42% of the weighting, leaving 58% coverage.

B provides stronger migration proof and a more substantiated delivery and operating proposal. Its 82.0 is a reason to advance to approval—not proof that implementation will succeed.

A’s correct outcome is **resolve and retest, or reject if the gaps cannot be closed**. Do not convert its unproven areas into claims that the product cannot perform them.

### What decision thresholds should the committee use?

The desk proposes the following starting policy:

| Result | Proposed decision |
|---|---|
| **80–100, gates passed, coverage at least 90%** | Eligible for award recommendation, subject to critical-criterion floors, sensitivity review and executable contract terms |
| **70–79, with no failed gate** | Conditional shortlist; close material gaps and rescore before approval |
| **Below 70** | Redesign the proposal, narrow the scope or consider another option |
| **Any gate on hold** | No final award approval until the hold is resolved |
| **Any failed gate** | Not eligible in its present form, regardless of total |

Before evaluation begins, designate critical criteria that must each earn at least **3**. The default candidates are C1, C3, C4, C6, C10 and C11, plus C2 and C5 where specialist depth or integrations are essential.

The 80-point and 90%-coverage thresholds are governance choices, not evidence-based success probabilities. Adjust them prospectively if needed; do not change them retrospectively to favour the preferred supplier.

---

# 10. How should scores become contractual and implementation acceptance conditions?

**Translate every material dependency into an owner, deliverable, price treatment and acceptance test.** Do not leave the scorecard detached from the statement of work.

For exit planning, the community-bank guide explicitly considers transition resources and capability. NYDFS’s third-party guidance also addresses transition planning, retention obligations and access removal. These sources support considering exit before the relationship ends; the detailed contract schedule below is the desk’s proposed implementation. ([federalreserve.gov](https://www.federalreserve.gov/publications/files/third-party-risk-management-guide-20240503.pdf))

### Attach this acceptance schedule to the procurement pack

| Required field | What to record |
|---|---|
| Requirement and test IDs | Direct links to the approved scope and demonstration evidence |
| Deliverable | Observable output—not simply “configured module” |
| Delivery method | Standard, configuration, custom development or third-party component |
| Accountable parties | Supplier, partner and buyer responsibilities separately |
| Dependencies | Data, access, decisions, licences, people and external systems |
| Commercial treatment | Included price, capped exposure or separately approved change |
| Acceptance method | Test data, expected result, evaluator and evidence retained |
| Defect handling | Severity, remedy, retest and consequences of non-acceptance |
| Handover | Runbooks, configuration inventory, training and operational ownership |
| Exit treatment | Export scope, timing, formats, assistance, retention and deletion process |

Have procurement and legal negotiate the final wording, including acceptance, remedies, audit rights, liability and termination. These are buyer-specific contractual decisions, not universal clauses supplied by this scorecard.

### Use a workbook that preserves the decision trail

Create separate tabs for:

1. Scope and weighting version.
2. Mandatory gates.
3. Requirements and supplier responses.
4. Tests, observations and defects.
5. Scores and evidence caps.
6. TCO and scenarios.
7. Contract dependencies and acceptance.
8. Decision, dissent and approvals.

A useful score-register header is:

`Requirement ID | Criterion | Weight | Critical? | Supplier/SKU/release | Delivery method | Suitability score | Evidence level | Earned score | Evidence reference | Gap | Owner | Due date | Contract reference | Retest result`

Preserve evaluator scores before moderation, the final agreed score and the reason for any change. Freeze each decision version. Repeat relevant tests after material changes to scope, configuration, delivery partner or enabled AI.

### What should the committee sign?

- [ ] The first-release scope and exclusions are understood.
- [ ] Every mandatory gate has accountable approval.
- [ ] Scores refer to the quoted configuration and proposed delivery team.
- [ ] Material evidence gaps and dissenting views are visible.
- [ ] Internal delivery and operating capacity are funded.
- [ ] Three-year costs and downside exposures are understood.
- [ ] Accepted dependencies appear in executable commercial documents.
- [ ] Migration, retrieval and exit have been tested at a representative level.
- [ ] Any referral or introduction arrangement is disclosed separately and has not altered scoring.

**The decision to defend is not “this supplier had the most features”. It is “this proposal met our non-negotiable conditions, demonstrated the workflows we need, and had an operating and commercial commitment we were prepared to accept”.**

---

# What does the public evidence establish—and what remains unproven?

The sources establish regulatory and professional considerations, documented product-mechanism examples and selected operational responsibilities. They do **not** establish the capabilities, negotiated price, delivery quality or security posture of a particular buyer’s proposed implementation.

Supplier documentation is evidence of what the supplier documents, not independent confirmation of a successful deployment. The OpenPages example is version-specific; the ServiceNow entitlement document is explicitly dated; the LogicGate API page is not an order form. The First Horizon posting illustrates responsibilities, not staffing economics.

This research does not validate the supplied desk notes’ market-size estimates, universal implementation-cost multiples or buying-cycle assumptions. None is needed to use the scorecard.

---

# Sources

Primary regulatory and standards sources underpin the control considerations. Product documents support only the specific examples attributed to them. URLs are provided below for source checking.

1. **Federal Reserve, FDIC and OCC — final third-party risk-management guidance announcement, 6 June 2023.** `https://www.federalreserve.gov/newsevents/pressreleases/bcreg20230606a.htm`
2. **Federal Reserve — SR 23-4 and Interagency Guidance on Third-Party Relationships: Risk Management.** `https://www.federalreserve.gov/supervisionreg/srletters/SR2304.pdf`
3. **Federal banking agencies — Third-Party Risk Management: A Guide for Community Banks, May 2024.** `https://www.federalreserve.gov/publications/files/third-party-risk-management-guide-20240503.pdf`
4. **NIST — SP 1305, Cybersecurity Framework 2.0: Quick-Start Guide for Cybersecurity Supply Chain Risk Management, October 2024.** `https://csrc.nist.gov/pubs/sp/1305/final`
5. **HHS — Guidance on HIPAA & Cloud Computing.** `https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html`
6. **NYDFS — Guidance on Managing Risks Related to Third-Party Service Providers, 21 October 2025.** `https://www.dfs.ny.gov/industry-guidance/industry-letters/il20251021-guidance-managing-risks-third-party`
7. **The IIA — Global Internal Audit Standards, issued 9 January 2024; Standard 7.1.** `https://www.theiia.org/globalassets/site/standards/globalinternalauditstandards_2024january9.pdf`
8. **IBM — OpenPages 9.1.x FastMap overview.** Search-accessible documentation; direct page retrieval was restricted during research. `https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview`
9. **ServiceNow — Integrated Risk Management entitlements, effective 9 May 2024.** `https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/other-document/entitlements/PROD14209.pdf`
10. **LogicGate — Risk Cloud API: Getting Started.** `https://www.logicgate.ai/developer/risk-cloud-api-getting-started/`
11. **First Horizon — Senior GRC Administrator employer posting, dated 9 April 2026.** Search-indexed employer content; full-page text was browser-limited. `https://recruiting.ultipro.com/FIR1007FTN/JobBoard/c005ef3e-175a-49c4-ba29-9f431f673944/OpportunityDetail?opportunityId=3d3259bf-0bb5-474b-8eb4-639fe8f63a6b`
12. **Verdantix — Riding The Wave Of Capability And Strategy Changes In The GRC Industry, 22 May 2026.** `https://www.verdantix.com/insights/blog/riding-the-wave-of-capability-and-strategy-changes-in-the-grc-industry`
13. **NIST — AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.** `https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf`