# Expert Q&A

Controlspan Research Desk · Last updated 28 October 2026

# What should buyers get from an expert conversation?

**Ask experts to identify the evidence that would change a purchasing decision—not simply describe what a good GRC platform should do.** This brief concentrates on migration, operating-model fit, implementation effort, administration, three-year ownership cost and exit readiness.

The questions are designed for CROs, CISOs, compliance leaders, internal audit, programme leads, enterprise architects and procurement teams. They can support an enterprise GRC software requirements checklist, a GRC RFP or a structured reference interview.

**Publication status:** this is a researched interview brief, not a completed interview. No interviews were conducted for this document. Suggested experts have not endorsed the questions or the draft answer framing. Each quotation space is deliberately blank.

The evidence paragraphs describe published material. The proposed tests, acceptance criteria and answer structures are **the desk’s recommendations for experts to challenge**, not attributed expert opinions or regulatory requirements. Supplier documentation establishes documented functionality or terms—not independently verified implementation outcomes.

---

# Who should be invited—and what should they disclose?

Use a mixed panel: a recognised researcher, an operating-model specialist, an assurance practitioner, an engineering practitioner and a sector specialist. Add a recent buyer who operated the selected platform after implementation; do not substitute a supplier-selected success story for that perspective.

| Suggested expert | Publicly documented basis for inclusion | Best questions to put to them | Interview safeguard |
|---|---|---|---|
| **Michael Rasmussen** | Founder of GRC 20/20 Research; his biography describes research and advisory work on GRC architecture and technology decisions, including relationships with suppliers and investors. ([grc2020.com](https://grc2020.com/person/michael-rasmussen/?utm_source=openai)) | Platform boundaries, implementation due diligence, architecture, commercial assumptions and exit. | Request disclosure of relevant supplier, investor and advisory relationships. |
| **Carole Switzer** | OCEG co-founder, with published work on GRC, controls and AI. ([oceg.org](https://www.oceg.org/carole/)) | Accountability, minimum viable scope, control ownership and adoption. | Distinguish operating-model guidance from claims about particular products. |
| **Norman Marks** | Former internal audit leader, CRO and compliance leader; author on risk management, SOX and internal audit. His biography also discloses work with software vendors. ([normanmarks.wordpress.com](https://normanmarks.wordpress.com/about/)) | Whether to buy, risk reporting, evidence quality and assurance independence. | Ask which conclusions come from direct operating experience and which are professional judgement. |
| **Ayoub Fandi** | Author of a first-person account accompanying an RSAC 2026 presentation on buying and building GRC tooling at GitLab. ([grcengineer.com](https://grcengineer.com/p/build-vs-buy-we-did-both-here-s-what-we-learned-rsac-2026-talk-summary)) | Workflow discovery, build-versus-buy boundaries, integrations and engineering ownership. | Test whether lessons transfer from an engineering-led technology company to the buyer’s regulated environment. |
| **Gregory C. Rasner** | Founder of Third Party Threat Hunting and former SVP of Cybersecurity Third-Party Risk at Truist, according to his published biography. ([rasner.com](https://rasner.com/speaker-kit/)) | Third-party dependencies, monitoring, resilience and supplier due diligence. | Disclose consulting, training and commercial relationships relevant to the discussion. |
| **Apostol Vassilev** | NIST researcher and an author of its 2025 adversarial machine-learning taxonomy. ([nist.gov](https://www.nist.gov/people/apostol-vassilev?utm_source=openai)) | AI evaluation, adversarial inputs, permissions and limits of assurance. | Seek technical principles, not government endorsement or comparative product recommendations; participation would be subject to applicable approvals. |

**Additional voices to recruit:** a bank GRC product owner, a healthcare security/compliance lead, a SOX programme owner, a platform administrator and a software procurement specialist. These are recruitment requirements, not identified or confirmed interviewees.

Before recording, ask every participant to disclose employment, implementation partnerships, referral arrangements, sponsored research and investments relevant to named suppliers. Record the date, product version, modules, deployment model and extent of hands-on experience behind each product-specific statement.

---

# Which questions should each buyer prioritise?

| Buyer | Start with | Decision output |
|---|---|---|
| CRO or executive sponsor | 1–3, 12, 14 | Buy/repair/defer decision, first-release scope and defensible risk reporting. |
| GRC programme lead | 4–7, 10–11 | Migration backlog, implementation assumptions and operating plan. |
| CISO or enterprise architect | 7–8, 15–17 | Integration tests, evidence controls, AI boundaries and portability proof. |
| Head of Compliance | 2, 9, 11, 13 | Accountability model, contributor workflow and obligation-change process. |
| Head of Internal Audit | 3, 8–9, 15 | Evidence quality, independent conclusions and AI review criteria. |
| Procurement and finance | 5, 12, 17 | Comparable scope, three-year USD cost model and exit provisions. |

---

---

# 1. What finding would make you tell us to repair our current arrangements rather than buy another GRC platform?

**A good answer should include a credible reason not to buy.** The interview should separate a product limitation from an ownership, process-design or configuration problem.

**Why it matters to buyers.** Deloitte’s published Optro implementation material describes an unnamed client using its platform mainly as a repository, with weak initial control design and an overly detailed audit configuration. The described intervention refreshed the existing deployment rather than treating replacement as the only route. This is a supplier-authored example, not evidence of how frequently that situation occurs. ([deloitte.com](https://www.deloitte.com/content/dam/assets-zone3/us/en/docs/services/audit-assurance/2026/aa-optro-placemat-0402.pdf))

**Put it to:** Norman Marks and Michael Rasmussen, followed by the incumbent platform owner.

**A strong answer should cover:**
- The business decision or assurance activity that is failing today.
- Whether the failure comes from missing capability, poor source data, unclear accountability or configuration choices.
- Four options: retain, repair, replace or build a bounded component.
- The evidence needed to reject each option, including the cost of keeping existing workarounds.
- Conditions that would justify delaying procurement until ownership or data readiness improves.

**Ask for proof:** a one-page option appraisal using the same workflow, service expectations and cost horizon for every option.

**Follow-up:** “If the incumbent could demonstrate this workflow next week, what remaining evidence would justify replacement?”

> **Expert quote — pending interview:** [Insert approved quotation, name, affiliation and interview date.]

---

# 2. What is the smallest useful first release—and what should deliberately remain outside it?

**A good answer should define a complete operating workflow, not a shopping list of modules.** Start with a named process, its accountable owner and the decision its output supports.

**Why it matters to buyers.** OCEG describes GRC as an integrated collection of capabilities for achieving objectives, addressing uncertainty and acting with integrity. That provides an operating-model basis for the interview; it does not establish that all capabilities must reside in one software product. ([oceg.org](https://www.oceg.org/ideas/what-is-grc/?utm_source=openai))

**Put it to:** Carole Switzer and Michael Rasmussen.

**A strong answer should cover:**
- The first legal entities, business units, record types and contributor groups in scope.
- A complete chain: obligation or risk → control → evidence → assessment → issue → approved resolution.
- Shared definitions that are essential, and specialist methods that should remain distinct.
- Explicit exclusions and the conditions for introducing later workflows.
- Which retained systems remain authoritative and how duplicate entry will be avoided.

**Ask for proof:** a scope charter with an owner and acceptance test for every first-release requirement.

For **ServiceNow IRM vs Archer vs IBM OpenPages**, ask experts to compare the buyer’s actual workflow rather than nominate a universal winner. Apply the same discipline to **AuditBoard vs Workiva for SOX controls management**. AuditBoard adopted the Optro name on 9 March 2026; use both names when searching historical references, but confirm the current quoted product and contracting entity. ([optro.ai](https://optro.ai/blog/auditboard-is-now-optro))

**Follow-up:** “Which requirement would you remove first if internal delivery capacity were cut—and what would that prevent us from doing?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 3. How should the platform combine risk information without manufacturing a misleading enterprise score?

**A good answer should explain the meaning and limitations of aggregation before discussing dashboards.** Ask the expert to demonstrate how a reported exposure connects to a business objective and a decision.

**Why it matters to buyers.** NIST IR 8286C Revision 1, published in December 2025, addresses integrating cybersecurity risk-register information into an enterprise risk portfolio and profile. Its focus is the connection between risk information and enterprise objectives—not simply collecting registers in one place. ([csrc.nist.gov](https://csrc.nist.gov/pubs/ir/8286/c/r1/final))

**Put it to:** Norman Marks and Michael Rasmussen, with the buyer’s risk methodology owner.

**A strong answer should cover:**
- Common definitions for impact, likelihood, time horizon, appetite and tolerance.
- How local scales are translated—and where translation would be inappropriate.
- Treatment of common causes, dependencies, overlapping scenarios and potential double counting.
- The distinction between exposure, control assessment, assessment confidence and data freshness.
- Who may challenge a score, approve an override and see the original assessment.

**Ask for proof:** take two business units with different scales and a shared supplier dependency. Require the expert to explain the resulting enterprise view, including what cannot defensibly be reduced to one number.

**Follow-up:** “What information would the board lose if we replaced this explanation with a single red, amber or green indicator?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 4. Before moving from spreadsheets to GRC software, what must be cleaned—and what history must remain recoverable?

**A good answer should separate cleansing, transformation, historical preservation and reconciliation.** “Import the spreadsheet” is not a sufficient migration scope.

**Why it matters to buyers.** IBM OpenPages documentation distinguishes configuration items, instance data and parent–child relationships. Its environment-migration tooling also has version and patch-level conditions. These distinctions illustrate why a migration plan must identify what is being moved and by which mechanism; they do not prove complete portability to another vendor. ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.0?topic=environments-supported-migration-items))

**Put it to:** Michael Rasmussen, a migration lead and a recent buyer who reconciled a completed migration.

**A strong answer should cover this proposed GRC data migration checklist:**

| Data area | Buyer question |
|---|---|
| Identity | Which immutable source identifiers survive, and how are target identifiers mapped? |
| Ownership | Who resolves missing current owners without overwriting historical authorship? |
| Relationships | How are controls linked to risks, obligations, entities, tests and findings? |
| History | Which approvals, prior results and changes remain searchable or are retained in an accessible archive? |
| Evidence | Are files copied or linked, and how are versions, access and broken links handled? |
| Reconciliation | Which counts, relationships, timestamps and selected records are checked before acceptance? |

**Ask for proof:** a trial migration containing duplicate controls, a departed owner, a closed finding, restricted evidence and a broken relationship. Require an exception log, not just a successful import message.

**Follow-up:** “Which defects must be fixed before pricing, which can be quarantined, and who can approve an unresolved exception?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 5. What would you need to know before giving us an implementation timeline or a fixed price?

**A good answer should expose assumptions before giving a duration or fee.** Ask for a dependency-based plan rather than a generic enterprise GRC implementation benchmark.

**Why it matters to buyers.** IBM’s migration documentation explicitly distinguishes development, user-acceptance and production environments and requires matching versions and patch levels for the described environment migration. That is one concrete example of a technical prerequisite a delivery estimate must accommodate. ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=guide-migrating-openpages-environments&utm_source=openai))

**Put it to:** Michael Rasmussen, the proposed delivery lead and an independent programme owner.

**A strong answer should cover:**
- The first accepted workflow, distinguished from technical installation and full programme completion.
- Source-data condition, historical scope, integrations and permission design.
- Buyer decision-making time, subject-matter expertise and control-owner availability.
- Configuration versus custom development, including upgrade and support responsibilities.
- Trial loads, business testing, cutover, rollback and post-launch support.
- Assumptions that trigger a scope change, the decision owner and the pricing mechanism.

**Ask for proof:** a work breakdown with buyer and partner responsibilities, named dependencies and an acceptance deliverable for each milestone.

Have the expert distinguish **elapsed time**, **partner effort** and **internal effort**. Require the estimate to state which activities can overlap and which must finish first.

**Follow-up:** “What is excluded from this fixed fee, and which excluded activity could prevent the first workflow from going live?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 6. Which demonstration would reveal that a platform fits our business—not just the supplier’s script?

**A good answer should prescribe exception tests using buyer-representative data.** The demonstration should show how work behaves when assumptions fail.

**Why it matters to buyers.** In his first-person account of GRC tooling at GitLab, Ayoub Fandi describes moving from surface-level requirements towards interviews about internal customers’ business problems. Treat this as a practitioner account worth probing, not a generalised failure-rate study. ([grcengineer.com](https://grcengineer.com/p/build-vs-buy-we-did-both-here-s-what-we-learned-rsac-2026-talk-summary))

**Put it to:** Ayoub Fandi and Michael Rasmussen.

**A strong answer should define a common demonstration script:**

| Scenario | Proposed observable acceptance evidence |
|---|---|
| Overdue remediation | Reassignment, escalation and original due-date history remain visible. |
| Disputed assessment | Challenge, rationale, approval and prior score can be reconstructed. |
| Failed integration | The failure and affected records are identifiable; stale evidence is not silently treated as current. |
| Restricted evidence | An unauthorised user cannot obtain the content through the tested interface, search or export route. |
| Administrator change | The buyer changes a field or approval step and demonstrates testing and rollback. |
| Bulk export | Records, relationships and the agreed supporting material can be reconciled outside the platform. |

**Ask for proof:** an evaluator log identifying the exact package, configuration, custom work and evidence shown.

Record **demonstrated**, **partially demonstrated**, **not demonstrated** and **roadmap** separately. Do not convert “not demonstrated” into an unsupported statement that the product lacks the capability.

**Follow-up:** “Which part of what we saw would our administrator be unable to reproduce without your team?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 7. What happens when an evidence connector fails halfway through a run?

**A good answer should describe detection, reconciliation, recovery and ownership—not merely confirm that a connector exists.**

**Why it matters to buyers.** Archer’s published data-feed documentation distinguishes completed, warning, faulted and other execution states. It also describes run history and counts of created, updated, deleted and failed records. That is useful evidence of the operational detail buyers should request, rather than relying on an integration catalogue. ([help.archerirm.cloud](https://help.archerirm.cloud/platform_2025_04/en-us/content/platform/integration/int_dfm_managing.htm))

**Put it to:** Ayoub Fandi and the buyer’s enterprise architect; require the proposed integration engineer to respond separately.

**A strong answer should cover:**
- Supported objects, synchronisation direction and the authoritative system for each field.
- Authentication, service-account privileges and secret rotation.
- Partial runs, rate limits, schema changes, deleted objects and expired credentials.
- Safe retries without unintended duplicates, conflict handling and reconciliation totals.
- Evidence timestamps and the difference between source state and collection time.
- Monitoring responsibility across the platform supplier, connector supplier, partner and buyer.

**Ask for proof:** interrupt a controlled test run, change a source record and restore access. Inspect what the platform collected, missed, duplicated or marked stale.

For each integration, request a dependency register containing its owner, support boundary, expected volume, freshness target, failure response and ongoing cost.

**Follow-up:** “Who receives the alert, who has authority to repair the failure, and how do we prove that the recovered evidence is complete?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 8. When is automatically collected evidence sufficient—and when does someone still need to test the control?

**A good answer should distinguish collecting information from reaching an assurance conclusion.** Ask what the evidence demonstrates, for which population and period, and with what limitations.

**Why it matters to buyers.** PCAOB AS 1105 requires auditors using company-produced information to address accuracy, completeness, precision and detail. It also addresses the reliability of externally sourced electronic information provided by the company. These are requirements for relevant PCAOB audits, not universal rules for every GRC workflow. ([pcaobus.org](https://pcaobus.org/oversight/standards/auditing-standards/details/AS1105))

**Put it to:** Norman Marks and the buyer’s internal or external assurance specialists.

**A strong answer should cover:**
- The control objective and whether the proposed test addresses design, operation or both.
- Source population, reporting period, exclusions and transformations.
- Whether a screenshot, configuration extract or ticket history answers the actual testing question.
- How contradictory, missing or stale evidence affects the conclusion.
- Which conclusions can be automated under an approved method and which require judgement.

**Ask for proof:** provide an access-review extract with an omitted subsidiary and a reporting period that does not match the review. Ask the expert to identify why a technically successful collection should not automatically produce a passing conclusion.

**Follow-up:** “What would make you reject this evidence even though it came directly from an authenticated system?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 9. How can audit, compliance and security share evidence without sharing away their independence?

**A good answer should separate common information from independent scope, judgement and approval rights.**

**Why it matters to buyers.** The IIA published refreshed Statements of Position on 8 July 2026. Its Three Lines material supports coordination and appropriate reliance while retaining safeguards for independence and objectivity, including where the chief audit executive has second-line responsibilities. ([theiia.org](https://www.theiia.org/en/resources/statements-of-position))

**Put it to:** Norman Marks, Carole Switzer and the buyer’s chief audit executive.

**A strong answer should cover:**
- Who owns the control, supplies evidence, performs testing and approves conclusions.
- Which evidence may be reused and what evaluation is needed before relying on another function’s work.
- Separate management responses, audit workpapers and final conclusions.
- Protection against self-review, inappropriate changes and restricted escalation.
- How platform administration is governed where administrators support functions being audited.

**Ask for proof:** run the same finding through control owner, compliance reviewer and auditor accounts. Test whether each can perform authorised work without rewriting another function’s conclusion or concealing its history.

The IIA’s 2026 statement explicitly treats independence as more than isolation: it addresses reporting lines, autonomy, access, resources and safeguards. Do not let an access-control demonstration stand in for that broader organisational assessment. ([theiia.org](https://www.theiia.org/globalassets/site/resources/statements-of-position/tlm_assurance_advice_support_effective_gov_en.pdf))

**Follow-up:** “Which independence risk remains even if every permission setting works correctly?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 10. Who will run the platform after the implementation partner leaves?

**A good answer should identify named capabilities, workload and backup coverage—not promise that the platform is easy to administer.**

**Why it matters to buyers.** A First Horizon Senior GRC Administrator vacancy posted in April 2026 described responsibilities spanning configuration governance, data integrity, release control, integration validation, access and licence alignment. One vacancy demonstrates a real operating-role specification; it does not establish a market-wide staffing ratio. ([recruiting.ultipro.com](https://recruiting.ultipro.com/FIR1007FTN/JobBoard/c005ef3e-175a-49c4-ba29-9f431f673944/OpportunityDetail?opportunityId=3d3259bf-0bb5-474b-8eb4-639fe8f63a6b&utm_source=openai))

**Put it to:** Carole Switzer, a practising platform administrator and the proposed partner’s support lead.

**A strong answer should distinguish:**
- Business product ownership and prioritisation.
- Platform configuration and release management.
- Data stewardship and taxonomy maintenance.
- Integration engineering and monitoring.
- Access administration and periodic review.
- Contributor support, training and documentation.

**Ask for proof:** an operating calendar and responsibility matrix with estimated effort based on the buyer’s expected volumes. Identify primary and backup owners, escalation routes, external support commitments and tasks that require specialist skills.

Make handover practical: have a buyer administrator change a workflow, investigate a failed load, provision a restricted role and restore a prior configuration in a test environment.

**Follow-up:** “If our main administrator is absent for a month, which activities stop—and which outside services would we need to buy?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 11. How would you establish that occasional control owners can use the platform successfully?

**A good answer should measure completed work and evidence quality, not logins alone.** Ask the expert to define a task-based adoption test before discussing training attendance.

**Why it matters to buyers.** Deloitte’s published example connects poor adoption with initial control and audit-workflow design, and describes subsequent configuration and methodology changes. It is a useful prompt to investigate workflow usability alongside training, rather than assuming training alone resolves adoption. ([deloitte.com](https://www.deloitte.com/content/dam/assets-zone3/us/en/docs/services/audit-assurance/2026/aa-optro-placemat-0402.pdf))

**Put it to:** Carole Switzer and the buyer’s programme lead, with actual occasional contributors in the test.

**A strong answer should cover:**
- A first-time contributor completing a representative task without a facilitator taking over.
- Delegation during absence, reassignment after a role change and recovery from rejected evidence.
- Clear due dates, evidence expectations and reasons for rejection.
- Accessibility and practical access from approved working environments.
- How genuine exceptions differ from avoidable off-platform work.

**Ask for proof:** establish a baseline and repeat the same task after configuration changes. Suggested measures are completion time, assistance requests, first-pass evidence acceptance and work requiring manual follow-up. Define the denominator, observation window and excluded cases for every metric.

**Follow-up:** “What result would persuade you to simplify the workflow rather than send users through another training session?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 12. What belongs in a three-year GRC total cost of ownership comparison?

**A good answer should normalise the same operating scope across quotes and keep unknown costs visible.** Do not treat a subscription quote as the complete implementation and operating budget.

**Why it matters to buyers.** ServiceNow’s published IRM entitlement document, effective 1 May 2025, distinguishes packages and user entitlements and identifies separately purchased Unified Compliance Framework access. It illustrates why buyers must examine usage rights and inclusions, not only a headline licence price. The buyer’s actual order form and incorporated terms must be checked separately. ([servicenow.com](https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/other-document/entitlements/PROD12020.pdf))

**Put it to:** Michael Rasmussen, procurement and finance, with suppliers answering the same clarification schedule.

**A strong answer should populate this proposed USD model:**

| Cost category | Required clarification |
|---|---|
| Subscription | Modules, entities, user categories, minimum commitments and expansion assumptions. |
| Contributor access | What occasional users, approvers, external auditors and suppliers may actually do. |
| Usage and infrastructure | APIs, connector transactions, AI usage, storage, environments and overages. |
| Content | Framework mappings, regulatory feeds, content licences and update responsibilities. |
| Implementation | Discovery, process design, configuration, custom development, migration and testing. |
| Internal delivery | Buyer hours for decisions, cleansing, integration, testing and training. |
| Ongoing operation | Administration, data stewardship, support, releases and integration maintenance. |
| Transition and renewal | Dual-running, legacy archive access, renewal changes and expansion scenarios. |
| Optional exit scenario | Export, extraction assistance, transformation, archive and replacement overlap. |

Use two views: **external cash expenditure** and **internal labour valued at approved loaded rates**. Report their combined economic cost without double counting labour already included in services charges.

The desk’s proposed model is: **three-year economic TCO = one-off delivery and transition costs + three years of recurring external costs + internal implementation and operating labour**. Add exit only when modelling a specified exit scenario.

Use **TBC**, not zero, for unquoted items. Keep taxes, discounting and accounting treatment explicit and subject to finance review.

**Follow-up:** “Which assumption changes the ranking of the shortlisted options, and what evidence would resolve it?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 13. How should a GRC platform distinguish a binding obligation from guidance, a proposal or an internal policy?

**A good answer should begin with legal-entity applicability, authoritative source and status—not a framework-count claim.** Ask how a change becomes an accountable business decision.

**Why it matters to buyers.** Current examples show why status and dates belong in the data model:

| Area | Verified status relevant to the interview | Proposed buyer test |
|---|---|---|
| US banking third-party risk | On **11 September 2026**, the agencies requested comment on proposed replacement guidance. The announcement describes supervisory guidance as non-binding and says existing guidance would be replaced when the new guidance is finalised. Do not present the proposal as a final rule. ([federalreserve.gov](https://www.federalreserve.gov/newsevents/pressreleases/bcreg20260911a.htm)) | Keep the proposal separate from the approved current methodology; record assessment and implementation decisions. |
| HIPAA Security Rule | HHS identifies the cybersecurity update as a proposal and states that the existing Security Rule remains in effect during rulemaking. The 2026 Unified Agenda lists the initiative under Long-Term Actions. ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html)) | Track proposed changes without marking them as newly effective obligations. |
| NYDFS Part 500 | The published covered-entity implementation timeline placed the specified MFA and asset-inventory provisions at **1 November 2025**—a past date, not an upcoming 2026 milestone. Applicability and exemptions still require review. ([dfs.ny.gov](https://www.dfs.ny.gov/system/files/documents/2023/11/cybersecurity_implementation_timeline_covered_entities.pdf?utm_source=openai)) | Apply the correct entity scope, effective date and approved exception treatment. |

**Put it to:** Carole Switzer and a qualified sector regulatory specialist; have the buyer’s counsel confirm applicability.

**A strong answer should cover:** source version, publication and effective dates, legal entity, applicability rationale, mapping owner, review status, implementation decision and historical reporting.

**Ask for proof:** change one obligation and show which policies, controls, evidence requests and owners are affected—without overwriting the previous interpretation.

**Follow-up:** “Who is accountable if the content feed is current but our applicability decision or control mapping is wrong?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 14. Can the third-party risk workflow explain a business-service dependency—not just a vendor score?

**A good answer should connect suppliers to the services and decisions that matter to the buyer.** Ask what happens operationally when a critical dependency deteriorates.

**Why it matters to buyers.** The federal agencies’ community-bank guide includes due-diligence considerations covering subcontractors, operational resilience, capabilities and service performance. It also addresses continuity and access to information in contracting. These considerations provide a useful interview foundation; the guide is a voluntary resource rather than a new set of legal requirements. ([federalreserve.gov](https://www.federalreserve.gov/frrs/guidance/third-party-risk-management-a-guide-for-community-banks.htm?utm_source=openai))

**Put it to:** Gregory Rasner, with procurement and the relevant business-service owner.

**A strong answer should cover:**
- The service supported, accountable owner and reason the relationship matters.
- Material subcontractors and shared dependencies, with unknowns explicitly recorded.
- Exposure across several vendors that depend on the same underlying provider.
- The decision triggered by deterioration: investigate, restrict, remediate, accept or exit.
- Who approves residual exposure and how the decision expires or is reconsidered.

**Ask for proof:** model a synthetic scenario in which two assessed vendors rely on the same underlying service. Ask which business services are affected and what evidence is missing before management can choose a response.

**Follow-up:** “If the questionnaire is complete but the dependency information is incomplete, what should the dashboard tell the business owner?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 15. How would you test whether GRC AI assistance reduces work without weakening evidence quality?

**A good answer should evaluate a defined task against a human-reviewed reference set and measure correction effort.** Faster drafting is not the acceptance criterion by itself.

**Why it matters to buyers.** NIST’s Generative AI Profile identifies confabulation: output can be inaccurate or internally inconsistent while appearing credible. That is directly relevant to evaluating generated summaries and mappings, but the NIST publication is not a certification of any GRC product. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf))

**Put it to:** Apostol Vassilev, Norman Marks and the buyer’s AI-risk lead.

**A strong answer should propose a bounded test:**
1. Select a task, such as drafting a control mapping or summarising an evidence package.
2. Establish an expert-reviewed reference and acceptable outcomes, including when the system should decline to conclude.
3. Include missing evidence, conflicting documents, obsolete policy versions and misleadingly similar controls.
4. Check whether each material claim points to the correct source and version.
5. Measure unsupported conclusions, missed contradictions, reviewer corrections and total task time.
6. Record the product, model/configuration information available, test date and retest triggers.

**Ask for proof:** a result register with case-level examples—not an unsupported overall accuracy percentage. Separate drafting, retrieval, mapping and approval tasks rather than averaging them into one score.

**Follow-up:** “Which error would make you disable the feature even if the average time saving looked attractive?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 16. What must be true before an AI feature can change a record, close an issue or trigger an external action?

**A good answer should distinguish permission to read, recommend, approve and execute.** Ask how the platform contains a mistaken or manipulated instruction.

**Why it matters to buyers.** NIST’s 2025 adversarial machine-learning taxonomy addresses attacks that manipulate AI inputs or interactions and can expose sensitive information. It supports examining adversarial behaviour in addition to ordinary output accuracy. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf?utm_source=openai))

**Put it to:** Apostol Vassilev and the buyer’s security architect; include the supplier engineer responsible for the feature.

**A strong answer should cover:**
- The identity and delegated authority under which an action runs.
- Authorisation enforced outside model-generated instructions.
- Restricted records, search results, citations, exports and downstream tool access.
- Approval boundaries and separation between proposing and executing a material change.
- Audit records, revocation, incident response and recovery of interrupted workflows.
- Data retention, model-provider access and contractual treatment of buyer information.

**Ask for proof:** use synthetic restricted evidence and an authorised account with limited rights. Include a document containing instructions that attempt to redirect the AI, then revoke access and retest retrieval and action paths.

Set a proposed stop condition for observed unauthorised disclosure or action, while making clear that passing a finite test set is not proof that all such failures are impossible.

**Follow-up:** “If we disable the AI feature now, what queued actions, delegated credentials or external side effects remain?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

# 17. Could we reconstruct a defensible record outside the platform before we sign the renewal?

**A good answer should demonstrate usable portability, not just an export button.** The test should cover both extraction and interpretation by a receiving team.

**Why it matters to buyers.** Archer’s July 2026 Engage export documentation describes assessment exports with optional attachments and specified access restrictions. It also identifies exclusions, including AI Autofill documents. This is a useful example of why export scope must be examined precisely; an assessment export is not proof of complete platform exit capability. ([community.archerirm.com](https://community.archerirm.com/hc/en-us/articles/52147245311379-Export-Assessment-in-Engage-is-Live))

**Put it to:** Michael Rasmussen, procurement, the enterprise architect and a replacement-programme owner.

**A strong answer should cover:**
- Records, identifiers, relationships, evidence and agreed historical information.
- Human-readable interpretation as well as machine-readable structure.
- Configuration documentation, custom logic and third-party content rights.
- Export permissions, volume constraints, delivery time and assistance charges.
- Archive access, retention decisions, deletion arrangements and the end of supplier access.
- Renewal notice, sourcing, security review, migration and dual-running dependencies.

**Ask for proof:** give an exported sample to someone who did not configure the platform. Ask them to reconstruct an obligation, linked control, test result, evidence, finding, approval and subsequent change.

Build the renewal decision calendar backwards from the contractual notice deadline using buyer-specific durations. Do not assume a universal replacement runway.

**Follow-up:** “Which part of this record would we lose, need to reconstruct manually or have to keep paying to access?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]

---

---

# How should the desk turn interviews into a defensible buyer recommendation?

**Convert each opinion into a decision, an evidence request and a testable condition.** Keep disagreements visible rather than editing them into artificial consensus.

Use this proposed interview evidence register:

| Field | What to record |
|---|---|
| Buyer decision | The purchase, scope, configuration or contractual decision affected. |
| Expert claim | The approved statement and its limits. |
| Basis | Direct experience, published documentation, observed test or professional judgement. |
| Context | Sector, organisation complexity, workflow, product package, version and date. |
| Counterexample | A situation in which the advice would not apply. |
| Buyer evidence | Artefact or demonstration needed to test the claim. |
| Result | Demonstrated, partial, not demonstrated or unresolved. |
| Commercial relationship | Relevant employment, advisory, referral or sponsorship disclosure. |
| Next action | Named owner, due date and consequence if unresolved. |

### Which supporting buyer tools should accompany the interviews?

Use the following proposed desk assets as working documents, not as substitutes for the interviews:

- **Requirements Scorecard / Scope Builder:** translate Questions 1–3 into first-release requirements and mandatory gates.
- **Migration Checklist / Migration X-Ray:** turn Questions 4–5 into a sample-based readiness assessment and remediation backlog.
- **Demo Script / Integration Check:** convert Questions 6–9 into repeatable supplier scenarios.
- **Operating Plan:** document the ownership and workload decisions from Questions 10–11.
- **TCO Calculator:** record confirmed USD costs and unresolved assumptions from Question 12.
- **AI Test Kit:** retain case-level results from Questions 15–16.
- **Exit Planner:** convert Question 17 into a portability test and renewal decision calendar.

Dedicated landing-page links should be added only when those assets are available. No availability or download claim is made here.

### What should not be inferred from this brief?

This research does **not** establish typical implementation durations, staffing ratios, negotiated enterprise GRC pricing or guaranteed savings. The supplied desk notes contain planning estimates, but those have not been promoted into verified market benchmarks.

There was no hands-on comparative platform test. Product documentation and supplier case material should therefore generate proof requests, not capability rankings. Regulatory examples are applicability checkpoints for qualified review, not legal advice or a claim that buying software establishes compliance.

The central interview test is: **what would the expert require the buyer to see, operate, reconcile and price before recommending commitment?**

---

# Sources

Sources below support the inline evidence. Older publications are retained where they remain relevant; release-specific documentation must be checked against the version and terms actually proposed to the buyer.

### Expert identification and practitioner perspectives

1. GRC 20/20 — Michael Rasmussen biography: `https://grc2020.com/person/michael-rasmussen/`
2. OCEG — Carole Switzer: `https://www.oceg.org/carole/`
3. Norman Marks — About Norman: `https://normanmarks.wordpress.com/about/`
4. GRC Engineer — Build vs. Buy: We Did Both. Here’s What We Learned: `https://grcengineer.com/p/build-vs-buy-we-did-both-here-s-what-we-learned-rsac-2026-talk-summary/`
5. Gregory and Maria Rasner — Speaker kit: `https://rasner.com/speaker-kit/`
6. NIST — Apostol Vassilev: `https://www.nist.gov/people/apostol-vassilev`

### Operating model, delivery and commercial evidence

7. OCEG — What is GRC?: `https://www.oceg.org/ideas/what-is-grc/`
8. Deloitte — From Implementation to Adoption and Beyond, 2026: `https://www.deloitte.com/content/dam/assets-zone3/us/en/docs/services/audit-assurance/2026/aa-optro-placemat-0402.pdf`
9. Optro — Rebrand announcement, 9 March 2026: `https://optro.ai/blog/auditboard-is-now-optro`
10. IBM — OpenPages supported migration items: `https://www.ibm.com/docs/en/openpages/9.1.x?topic=environments-supported-migration-items`
11. IBM — Migrating OpenPages environments: `https://www.ibm.com/docs/en/openpages/9.1.x?topic=guide-migrating-openpages-environments`
12. Archer — Managing Data Feeds, version-specific documentation: `https://help.archerirm.cloud/platform_2025_04/en-us/content/platform/integration/int_dfm_managing.htm`
13. First Horizon recruitment listing — Senior GRC Administrator: `https://recruiting.ultipro.com/FIR1007FTN/JobBoard/c005ef3e-175a-49c4-ba29-9f431f673944/OpportunityDetail?opportunityId=3d3259bf-0bb5-474b-8eb4-639fe8f63a6b`
14. ServiceNow — IRM entitlements, effective 1 May 2025: `https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/other-document/entitlements/PROD12020.pdf`
15. Archer — Export Assessment in Engage, updated 1 July 2026: `https://community.archerirm.com/hc/en-us/articles/52147245311379-Export-Assessment-in-Engage-is-Live`

### Assurance, risk and regulatory sources

16. NIST — IR 8286C Revision 1, December 2025: `https://csrc.nist.gov/pubs/ir/8286/c/r1/final`
17. PCAOB — AS 1105, Audit Evidence: `https://pcaobus.org/oversight/standards/auditing-standards/details/AS1105`
18. The IIA — Statements of Position, including July 2026 updates: `https://www.theiia.org/en/resources/statements-of-position`
19. 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`
20. Federal Reserve — SR 24-2, community-bank third-party risk guide and status: `https://www.federalreserve.gov/supervisionreg/srletters/SR2402.htm`
21. Federal Reserve — Third-Party Risk Management: A Guide for Community Banks: `https://www.federalreserve.gov/frrs/guidance/third-party-risk-management-a-guide-for-community-banks.htm`
22. Federal Reserve — Proposed third-party risk management guidance, 11 September 2026: `https://www.federalreserve.gov/newsevents/pressreleases/bcreg20260911a.htm`
23. HHS — HIPAA Security Rule NPRM: `https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html`
24. Reginfo.gov — Unified Agenda search results for RIN 0945-AA22: `https://www.reginfo.gov/public/Forward?Image61.x=19&Image61.y=7&SearchTarget=Agenda&textfield=0945-AA22+`
25. NYDFS — Cybersecurity Resource Center: `https://www.dfs.ny.gov/industry_guidance/cybersecurity`
26. NYDFS — Covered-entity implementation timeline: `https://www.dfs.ny.gov/system/files/documents/2023/11/cybersecurity_implementation_timeline_covered_entities.pdf`

### AI evaluation and security

27. NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: `https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf`
28. NIST — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, March 2025: `https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf`