Quick orientation: the urgent request that started this

• How often does your board or an examiner ask for an enterprise-level heat map on short notice? Options: Multiple times a year, Once a quarter, Once a year, Rarely or never
• Tell me about the last time your team had 48 hours to produce a board-ready risk heat map, what happened and who scrambled?
• When you assemble board materials today, which primary artifacts do you pull from? Options: Spreadsheets from business units, Legacy risk registers, Point-in-time PowerPoint slides, Operational dashboards or BI reports, Audit or control reports, Other
• Who on your team owns producing the board-ready deliverable under that time pressure? Options: CRO, Head of ERM, Risk operations lead, Internal audit, Business unit risk lead, Other
• If producing a board-ready heat map within 48 hours stayed impossible, would that trigger immediate investment in a new platform? Options: Yes, within 30 days, Yes, but within the quarter, Maybe, depending on cost, No, not on its own

Where the current process fractures when time matters

• Imagine your enterprise exposure can be masked by inconsistent scores, where does that mismatch most commonly begin?
• Which business unit or entity tends to deliver the most incompatible risk registers? Options: Front-office business units, Shared services and support functions, Regional or subsidiary entities, Legal and compliance, Not sure
• Walk me through the handoff from a business unit spreadsheet to the board slide, step by step.
• How many different scoring scales are actively used across your business units today? Options: One unified scale, 2 to 3 different scales, 4 to 6 different scales, More than six, Do not know
• Name the single failure in that chain which, if unresolved, would make you stop a pilot immediately.

How you label, score, and try to make numbers comparable

• Where your taxonomy allows assessor judgment, how often do people fall back to local conventions instead of enterprise rules? Options: Almost always, Often, Occasionally, Rarely, Never
• Describe one recent assessment where scoring differences materially changed an enterprise trend or decision.
• Select the scoring inputs that are currently automated for you Options: Loss history and claims, Operational metrics (availability, incidents), KRI feeds from monitoring tools, External market or credit data, Manual assessor judgment only, Other
• Who is currently responsible for maintaining scoring rules and how are changes governed?
• Assuming a pilot demonstrates consistent scoring across units, who must approve enterprise rollout and how quickly could they do so?

Data plumbing and integration constraints we cannot ignore

• Imagine an integration fails during a pilot, which system outage would make the pilot invalid?
• List the systems that must feed KRIs and assessments for this engagement Options: Core banking or policy ledger, Claims management, Policy administration, Fraud and incident systems, HR and payroll, Data warehouse or lake, Custom SFTP or file feeds, Other
• Identify the teams that own APIs or data extracts for those sources and the likely point of contact role Options: CIO or platform team, Data engineering, Line-of-business IT, Third-party vendor team, No obvious owner
• Rate the readiness of the historical data you expect us to migrate Options: Ready with minor mapping, Requires significant cleaning and mapping, Mostly unstructured and needs transformation, Not available for migration, Unknown
• Name the single integration gap that would stop the project before deployment
• Are APIs or programmatic extracts available for the systems you listed? Options: Yes for most, Partial availability, No, flat files only, Unknown

Who decides this and how they will judge it

• Suppose a regulator asks for evidence that taxonomies are enforced, who will be your internal arbiter of acceptance? Options: Internal audit, Head of ERM, CRO, Compliance, Board committee, Other
• Select the stakeholders who must be satisfied for procurement to move forward Options: CRO, Head of ERM, Internal audit, CIO or IT, CFO or procurement, Compliance, Board representative
• Describe how internal audit will evaluate whether the platform produces audit-ready evidence
• When the pilot meets scoring and reporting criteria, what internal process would let you sign within 30 days?

Internal friction and the blockers that slow change

• Identify who has pushed back in previous technology rollouts and why they resisted
• When a new process was introduced before, which factors most often stopped first-line adoption? Options: Too many fields or complexity, Lack of time in day job, Unclear ownership, No incentives or KPIs changed, Technical issues
• Tell me about the training model that showed the best sustained adoption in past rollouts Options: Short focused workshops, Embedded on-the-job coaching, Self-paced modules, Train-the-trainer program, Other
• Is there a single person or committee inside who could block deployment if they are not convinced? Options: Yes, name and role in follow-up, No single blocker, There is a committee

Other paths you are weighing before you switch

• For you to stay with the current approach, what would have to be true about it?
• Identify the alternative paths you are actively evaluating right now Options: Keep spreadsheets and manual process, Build a bespoke internal solution, Buy a large enterprise GRC suite, Buy a lightweight point solution, Evaluate other vendor platforms, Other
• Has anyone inside proposed solving this without an outside vendor, and if so who and why? Options: Yes, engineering proposed build, Yes, risk analytics proposed build, No internal proposal, Other
• What would make you choose to stay with the incumbent or an internal build rather than move to an outside platform?

Pilot scope that would convince the board and the examiner

• Given a time-boxed pilot that must validate KRI feeds, scoring consistency, and board reports, which of those is highest risk for you? Options: Scoring consistency, KRI feed reliability, Board-ready report clarity, Data migration and mapping, User adoption
• What duration pilot are you willing to run and who from your organization will resource it? Options: 2 weeks, 4 weeks, 8 weeks, 12 weeks, Depends on scope
• List the acceptance criteria that would make a pilot an unequivocal success Options: Scoring variance below agreed threshold, Automated KRI refresh within agreed window, On-demand board-ready report produced, Complete audit trail for sample assessments, Minimum user adoption threshold met
• What would stop you from signing the week after a successful pilot, even if metrics look good?
• What timeline constraints do regulators or exam cycles impose on your decision? Options: Immediate (within 30 days), Within the current quarter, Within six months, No fixed regulatory deadline

Practical next steps and the immediate commitments needed

• Should we move forward, who on your side must be available in week one to avoid delays?
• Provide the technical contact roles we should engage to scope integrations Options: API product owner, Data engineering lead, Line-of-business IT lead, Security/infosec contact, Vendor operations contact
• How much of the deployment work should your team own versus the seller's implementation team? Options: Seller handles most work, Even split 50/50, Buyer handles most work, Undecided
• What final internal approval or budget threshold would need to be cleared before you can run the pilot?

• Solution Experience: Standardize Taxonomy, Scoring, KRIs, and Board Reporting

• Confirm the current state and its cost to your team
• Customer confirms the demonstrated taxonomy normalization eliminates the two-week consolidation and meets the 48-hour board request.
• Deliver a pilot design and proposed acceptance criteria document based on the validated scenario within five business days.
• Customer confirms the standardized scoring and KRI mapping produce a consistent enterprise risk view that surfaces concentration risk previously masked.
• Run your real scenario through taxonomy normalization and scoring
• Provide the six current risk spreadsheets and a representative recent board request timeline to support the pilot configuration.
• Agreement on pilot acceptance criteria and a clear next-step owner list and timeline.
• Show KRI feed mapping and board-ready heat map for the same scenario
• Identify the head of ERM, internal audit contact, and the CIO integration owner who will participate in pilot decisions.
• Validate the outcome with a direct question
• Prepare an initial taxonomy-to-field mapping and KRI feed wiring plan for the selected scenario and share before the pilot kickoff.
• Agree pilot acceptance criteria and next steps

• Solution Experience: Standardize Taxonomy, Scoring, KRIs, and Board Reporting
• Solution Experience Deck
• Solution Brief — Taxonomy, Scoring, and Board Reporting

• meeting
• slides
• document

• Deploy unified risk taxonomy
• Configure quantitative scoring models
• Migrate historical risk registers
• Set up multi-entity hierarchy and consolidation
• Configure assessment workflows and automation
• Integrate key risk indicator data feeds
• Enable real-time risk dashboards
• Implement loss event tracking
• Build board-ready heat map reports
• Configure regulatory reporting templates
• Enable audit-ready evidence repository
• Integrate with compliance and audit systems
• Train risk owners and administrators

Deploy unified risk taxonomy

• Do you have an existing ERM taxonomy document, risk universe spreadsheet, or operating model to import? Options: Yes, No
• Please list the risk domains and subdomains that must be present (example: Operational, Credit, Market, Strategic, Cyber, Compliance).
• Estimate the current count of distinct risk categories and subcategories in your spreadsheets or registers. Options: <50, 50-200, 201-500, 500+
• Name the stakeholder or committee that must approve taxonomy changes (head of ERM, internal audit, board risk committee). Options: Head of ERM, Internal Audit, Board Risk Committee, CRO, Other
• Describe mandatory mapping rules from legacy spreadsheet columns to taxonomy fields (for example: map 'Risk Type' to Domain>Subdomain, 'Likelihood' to scoring field).
• Indicate any regulator alignment required in the taxonomy (examples: ORSA reporting categories, OCC examiner categories, state-level regulator views). Options: ORSA, OCC guidance, NYDFS, State regulator, None specified, Other

Configure quantitative scoring models

• For scoring scale preference, which approach do you need (examples: 1-5 ordinal, 1-10 granular, probability x impact matrix)? Options: 1-5 ordinal, 1-10 granular, Probability x Impact, Custom formula
• List the quantitative inputs currently available to feed scores (examples: incident counts from claims ledger, exposure amounts from general ledger, SLA breach counts from monitoring).
• Specify any regulator-mandated scoring conventions we must support (for instance ORSA severity bands or capital impact buckets). Options: ORSA severity bands, Capital impact buckets, Examiner-prescribed methods, None
• Identify the owner who will maintain scoring parameters (business unit risk lead, analytics team, ERM administrator). Options: Business unit risk lead, Analytics team, ERM admin, CRO office, Other
• Confirm the acceptable inter-rater variance threshold for scoring consistency across business units (for example: percent agreement or standard deviation threshold). Options: Percent agreement ≥ 90%, Std dev threshold specified, No formal threshold yet
• State whether you require built-in statistical distributions, Monte Carlo support, or only deterministic formulas for score calculations. Options: Deterministic formulas only, Built-in distributions (e.g., normal, Poisson), Monte Carlo simulation support, Custom code hooks

Migrate historical risk registers

• Do you have historical risk registers in Excel, SharePoint, legacy GRC exports, or CSVs that must be migrated into the platform? Options: Yes - Excel/CSV, Yes - Legacy GRC export, Yes - SharePoint workbooks, No historical data
• Identify the file formats and storage locations for those registers (examples: Excel workbooks in SharePoint, CSV exports from legacy GRC, archived PDFs).
• Provide an estimated record count to migrate (rows / number of spreadsheets / number of registers). Options: <1,000 rows, 1,000-10,000 rows, 10,001-50,000 rows, 50,000+
• What migration completeness threshold will validate success (for example: 95% of records migrated with field-level accuracy and reconciled to source)? Options: ≥95% field-level accuracy, ≥98% accuracy, Custom threshold (specify in details)
• Detail any cleansing rules required during migration (examples: deduplicate by risk ID, harmonize entity names, convert exposure units).
• Name the internal owner who will provide source context, annotations, and sign-off for migrated historical entries. Options: ERM team, Business unit risk owners, Internal Audit, Finance, Other

Set up multi-entity hierarchy and consolidation

• List the legal entities and business units that must be modeled (include holding company, regulated subsidiaries, and FRB/OCC-reportable entities).
• Explain the preferred roll-up logic for board-level consolidation (for example: by legal entity to holding company, by line of business across entities).
• Identify the source of legal entity identifiers we must map (for example: LEI, internal legal code, tax ID, chart of accounts codes). Options: LEI, Internal legal code, Tax ID, Chart of accounts code, Other
• Describe required currency or unit normalization rules when consolidating quantitative exposure or loss figures (example: translate to USD, normalize premiums to annualized amounts).
• State whether statutory or regulator-specific roll-up views are required (examples: ORSA consolidated view, state-level reporting slices). Options: Yes - ORSA consolidated, Yes - state-level, No regulator-specific roll-ups, Other
• Who will own maintenance of the multi-entity hierarchy and approve entity additions or retirements? Options: Corporate entity management, Finance, ERM team, CRO office, Other

Configure assessment workflows and automation

• Would you like recurring assessment schedules aligned to your regulatory and business calendar (examples: quarterly ORSA refresh, annual compliance attestations)? Options: Yes - align to regulatory cycles, Yes - custom business calendar, No recurring schedule
• Define notification and escalation rules for overdue assessments or failed controls (for example: email to risk owner, escalate to head of ERM after 7 days).
• Who are the expected assessment respondents (examples: first-line process owners, control owners, centralized risk teams)? Options: First-line owners, Control owners, Central risk team, Other
• When an automated KRI threshold breach occurs, explain preferred remediation routing (examples: create incident, assign to business unit, notify internal audit).
• Please indicate if assessment templates should be domain-specific or business-unit-specific and whether custom evidence fields are required for regulators. Options: Domain-specific templates, Business-unit-specific templates, Both, No templates required
• Is automated reminder and completion reporting required for business units and for the board (for example weekly progress to CRO and monthly to board secretary)? Options: Yes - both business unit and board, Yes - business unit only, No

Integrate key risk indicator data feeds

• Identify the source systems that will provide KRI feeds (examples: core banking ledger, claims system, SIEM, merchant processing, policy administration). Options: Core banking/GL, Claims system, SIEM/security, Policy admin, CRM, Other
• Specify the required update frequency for KRIs to satisfy board and regulator needs (examples: real-time, hourly, daily, weekly). Options: Real-time/streaming, Hourly, Daily, Weekly
• Define minimum data quality thresholds for KRI acceptance (for example: null rate <2%, reconciliation variance <1%).
• Name the team or role that will maintain connectors and credential rotation for KRI endpoints. Options: Platform ops, IT integrations, ERM admin, Business unit IT, Other
• Confirm whether secure transfer mechanisms are mandated for KRI feeds by your security team (examples: SFTP, mutual TLS, VPN). Options: SFTP required, Mutual TLS required, VPN required, No special requirement
• Provide transformation rules to apply to KRI data prior to ingestion (examples: compute 30-day rolling average, map account IDs to business unit).

Enable real-time risk dashboards

• Outline the executive KPIs and KRIs required on the board-level dashboard (examples: top 10 risks by exposure, concentration limits, active KRI breaches).
• Indicate target refresh cadence to meet the 48-hour board information expectation (options include real-time, hourly, daily). Options: Real-time, Hourly, Daily
• Explain required drill-through behavior from a heat map to source artifacts (examples: ability to drill to loss event record, underlying spreadsheet row, or transaction in the claims ledger).
• Who should have export or snapshot privileges for board dashboards for examiners or audit (examples: board secretary, internal audit, CRO)? Options: Board secretary, Internal audit, CRO, Head of ERM, Other
• State whether role-based dashboards are required so that business unit heads see different roll-ups than the CRO and the board. Options: Yes - role-based required, No - single view
• Provide performance targets for live dashboards (example targets: widget load <3s, full dashboard <5s) to ensure usability during board meetings.

Implement loss event tracking

• Have you maintained a loss event register or claims feed that should be ingested for loss tracking and trend analysis? Options: Yes - structured register, Yes - claims system feed, No
• Detail the loss attributes that must be captured for each event (examples: event date, loss amount, root cause, business unit, remediation status, regulator impact).
• Indicate the required historical lookback for loss events used in trend analysis (examples: 3 years, 5 years, since last regulatory exam). Options: 3 years, 5 years, Since last exam, Full history available
• Please indicate the team responsible for validating financial loss amounts against the general ledger or claims system during reconciliation. Options: Finance/GL, Claims accounting, ERM reconciliation team, Internal audit
• Are your internal audit evidence requirements for loss events stricter than standard recordkeeping (for example archived PDFs with immutable audit trail and timestamps)? Options: Yes - stricter, No - standard retention
• State required retention periods and archival formats for loss events to satisfy regulators (example: 7 years, immutable PDF with audit trail). Options: 3 years, 5 years, 7 years, Regulator-specified

Build board-ready heat map reports

• Detail required board report formats (examples: printable PDF packet, interactive dashboard link, slide deck with executive summary). Options: Printable PDF, Interactive dashboard link, Slide deck, All of the above
• Indicate target SLA for producing an updated heat map after a material event or chair request (for example: within 48 hours). Options: <24 hours, 48 hours, 72 hours, Custom
• Identify the evidence that will validate board-readiness for a heat map (examples: drill-through to source spreadsheet row with audit trail, reconciled KRI feed timestamps, sign-off log).
• Explain required summarization levels for the board view versus management view (example: board needs top-level risk exposures and concentrations; management needs control-level detail).
• Who will be the approver for the final board packet (examples: CRO, board secretary, head of ERM)? Options: CRO, Board secretary, Head of ERM, Committee chair
• Provide any board formatting or accessibility requirements (examples: single slide per risk, appendix with drill-through, color-blind friendly palettes).

Configure regulatory reporting templates

• List the regulatory templates or reports you must produce from the platform (examples: ORSA submission extracts, OCC response packs, state regulator spreadsheets).
• Specify required data fields and formats for each regulator view (examples: exposure by state, aggregate losses by line of business, capital impact fields).
• Indicate whether regulators require time-stamped evidence attached to submitted reports (examples: audit trail for each aggregated cell used in the submission). Options: Yes - time-stamped evidence required, No
• Who will be responsible for final regulatory report sign-off and submission (examples: CRO, compliance officer, CFO)? Options: CRO, Compliance officer, CFO, Other
• Provide any regulator-specific thresholds or tolerances that should drive alerts or exceptions in template outputs (examples: concentration > X% of premium, loss ratio thresholds).
• State whether you require scheduled automated exports for regulators and the desired cadence (examples: quarterly ORSA extract, monthly regulator snapshot). Options: Daily, Weekly, Monthly, Quarterly, On-demand

• stakeholders
• gaps
• current_state
• success_criteria
• decision_readiness
• desired_state
• stakeholders
• success_criteria
• gaps
• current_state
• desired_state
• decision_readiness
• stakeholders
• desired_state
• success_criteria
• decision_readiness
• current_state
• gaps
• decision_readiness
• current_state
• decision_readiness
• decision_readiness
• decision_readiness

• Subscription Order Form
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Data Access Authorization
• Acceptance Criteria Appendix
• Regulatory Evidence & Board Reporting Governance Addendum
• Financial Services Compliance Addendum (SOC2 and Data Residency)
• Change Order Agreement

• Go-live Health Check (weeks 1-4)
• First Measurement — Initial Outcomes Review (weeks 4-10)
• 90-Day Outcomes Review — Realization and Remediation
• Quarterly Business Review — Operational Stability and Backlog
• Annual Regulatory Evidence Audit and Review

• Publish the prioritized enhancement list with expected delivery quarters and business impact notes.
• Publish the 90-day remediation plan with resolution dates and specific acceptance verification steps.
• Deliver corrected reports and refreshed evidence packages for any items that failed the spot-checks.
• Update the issues and enhancement channel with the prioritized remediation items and expected completion dates.
• Trend review for named metrics
• Ensure metric trends are progressing toward the Solution Evaluation targets or have a documented plan to get there.
• Agree a prioritized enhancement roadmap focused on closing gaps that affect regulator and board deliverables.
• Confirm there are no unresolved operational defects that will prevent timely regulator evidence delivery in the next quarter.
• Re-confirm success criteria and owners
• Produce a one-page operational status summary for the regulator readiness folder.
• Schedule targeted remediation sprints for any high-severity defects affecting board or regulator reporting.
• Full evidence completeness audit
• Demonstrate that a high percentage of regulator evidence requests are satisfied by platform-stored artifacts.
• Confirm the average time to assemble regulatory evidence is at or improving toward the Solution Evaluation target.
• Ensure long-term retention and archival controls for retired spreadsheets meet audit expectations.
• Produce the annual evidence audit report and publish it to the regulator evidence folder.
• Document any compensating controls or remediation steps for high-severity gaps with expected completion dates.
• Refresh retention and access control policies for archived incumbent artifacts and publish the change log.
• Deployment and KRI feed connections verified as operational for the pilot datasets.
• All critical blockers identified and owners assigned with target resolution dates.
• Early adoption signals documented and a short list of adoption actions agreed.
• Produce a short remediation plan for critical go-live defects with target dates for closure.
• Deliver a data-migration verification report showing record counts and checksum results for migrated registers.
• Circulate an initial user adoption summary for the first 30 days for async review.
• Present first measurement data
• Understand why initial outcomes differ from targets recorded in the Solution Evaluation stage and document the root causes.
• Agree a time-bound remediation plan to reduce manual reporting hours and shorten heat map production time.
• Confirm the incumbent spreadsheet wind-down plan is in motion or set dates to complete it.
• Deliver a remediation task list with owners and completion dates for all items that prevent meeting the Solution Evaluation targets.
• Lock legacy spreadsheet registers to read-only and publish the archive location and retention policy.
• Provide sampled audit evidence packages and a checklist showing chain-of-custody for each item reviewed.
• Present outcome data against Solution Evaluation targets
• Establish a clear list of residual remediation items that will bring outcomes to the Solution Evaluation targets and set deadlines.
• Confirm board-ready reports meet the regulator and board content expectations in the sampled cases.
• Ensure audit evidence samples demonstrate required traceability and retention policy compliance.
• Deployment and migration validation
• Operational issues and remediation burn-down
• Time-to-assemble evidence measurement
• Document and time-box remediation actions
• Diagnose root causes for gaps
• Enhancement request backlog and prioritization
• Validate board-ready report delivery and accuracy
• Retention, archival proof, and chain-of-custody
• Incumbent system decommissioning and data archive status
• Early adoption signals and usage patterns
• Regulatory calendar and upcoming evidence needs
• Blockers and open issues
• Outstanding high-severity items and long-term plan
• Audit evidence completeness spot-check
• Validate sample audit-ready evidence
• Agree immediate remediation actions
• Agree corrective actions and timeline