# Direct questions

Controlspan Research Desk · Last updated 28 October 2026

# 1. What is an enterprise GRC platform, and do we need one rather than specialist compliance software?

An enterprise GRC platform connects risk, compliance and assurance work across functions; a specialist application may be sufficient when the requirement is narrower. IBM describes OpenPages as a modular platform spanning risk, compliance and audit, while ServiceNow positions IRM across IT, cyber and business operations. Those descriptions establish intended scope, not equivalent capability or suitability for your organisation. [IBM OpenPages](https://www.ibm.com/products/openpages) · [ServiceNow IRM](https://www.servicenow.com/products/integrated-risk-management.html). ([ibm.com](https://www.ibm.com/products/openpages))

**Our recommendation: choose the operating model before the product category.** Ask whether the organisation needs to share merely evidence files, or also ownership, risk assessments, control definitions, exceptions and reporting decisions.

| Your first requirement | Evaluation starting point |
|---|---|
| Collect security evidence against defined requirements | Test an evidence-led workflow before buying enterprise breadth |
| Manage SOX testing and financial-control deficiencies | Start with controls, testing and assurance workflows |
| Aggregate operational risks across business units | Start with entity structure, risk methodology and reporting |
| Manage supplier relationships throughout their lifecycle | Start with third-party inventory, due diligence, monitoring and exit |
| Coordinate several of these activities | Test a shared data model alongside specialist functional depth |

Keep three options open: one enterprise platform, connected specialist systems, or improvement of the existing estate. In a connected architecture, explicitly nominate the authoritative system for each object: supplier, control, finding, ticket and evidence file.

**Decision test:** if the team cannot explain which records should be shared and which decisions must remain separate, pause the shortlist and resolve those questions first.

---

# 2. What are the best enterprise GRC platforms for mid-sized banks?

Build the shortlist around the bank’s first workflow and delivery capacity, rather than selecting a universal “best” platform. Banking supervisors’ third-party guidance covers planning, due diligence, contracting, monitoring and termination; a questionnaire-only demonstration therefore does not demonstrate that full lifecycle. [Interagency guidance announcement](https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html). ([occ.gov](https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html?utm_source=openai))

The following are **starting hypotheses for evaluation**, not rankings:

| Starting hypothesis | Candidates supported by reviewed public material | What the bank should prove |
|---|---|---|
| Financial-services-specific workflows and content are central | Ncontracts explicitly offers bank-focused risk, compliance and vendor-management solutions. [Bank offering](https://www.ncontracts.com/bank-risk-management) | Coverage of your charter, activities, entities and examination process; responsibility for content updates |
| Configurable, phased workflows are the priority | LogicGate sells Risk Cloud applications and Power User licences. [Commercial model](https://www.logicgate.ai/platform/pricing/) | Whether your administrators can maintain assessments, approvals and reports without repeated external work |
| Several enterprise risk domains must connect | ServiceNow IRM and IBM OpenPages describe cross-domain platforms. [ServiceNow](https://www.servicenow.com/products/integrated-risk-management.html) · [IBM](https://www.ibm.com/products/openpages) | Shared entity structure, specialist depth, access boundaries and sustainable administration |
| Integration with an established Archer estate matters | Archer documents imports, feeds, gateways, publications and APIs. [Integration methods](https://help.archerirm.cloud/platform_2024_09/en-us/content/platform/integration/int_overview.htm) | Whether reuse is genuinely preferable to redesign or replacement |

These supplier statements support consideration, not selection. ([ncontracts.com](https://www.ncontracts.com/bank-risk-management))

Give every candidate the same bank-specific scenario: a critical service provider changes a subcontractor, its assessment becomes overdue, a control fails, management accepts a temporary exception, and a committee requests the decision history.

Ask references about configuration effort, retained spreadsheets, administrator workload and the first examination after implementation. A reference from a similar operating model is more useful to this evaluation than an impressive customer logo alone.

---

# 3. How should we compare ServiceNow IRM vs Archer vs IBM OpenPages?

Compare the proposed deployment, data model and operating responsibilities—not just the three brand names. Public documentation identifies meaningful differences, but it does not establish a winner for an unspecified implementation.

| Platform | What reviewed documentation establishes | Buyer-specific question |
|---|---|---|
| ServiceNow IRM | Connects risk and compliance across IT, cyber and business operations. Its data-model design service explicitly addresses entity structures, source/target inputs and integrations. [IRM overview](https://www.servicenow.com/products/integrated-risk-management.html) · [Design service description](https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/legal/irm-data-model-design-tier-2-service-description.pdf) | Who owns the GRC backlog within the wider platform team, and which existing data is reliable enough to reuse? |
| Archer | Documents several integration approaches; its ServiceNow integration requires configuration and is not described as turnkey for every use case. [Integration guide](https://help.archerirm.cloud/exchange/content/exchange/integrations/servicenow.htm) | Which existing applications and integrations remain supported, and what requires rebuilding? |
| IBM OpenPages | Offers modular cloud and on-premises options. Its pricing page also identifies features not supported in the as-a-Service offering. [Product](https://www.ibm.com/products/openpages) · [Deployment qualifications](https://www.ibm.com/products/openpages/pricing) | Does the exact deployment include the reporting, customisation, search and integration capabilities shown in the demonstration? |

Treat these as documentation-based distinctions, not tested performance comparisons. ([servicenow.com](https://www.servicenow.com/products/integrated-risk-management.html?utm_source=openai))

Require the proposal to identify:

- Product, release, deployment model and purchased modules.
- Entity hierarchy and ownership of reference data.
- Supported configuration versus custom code.
- Integration components, fees and support responsibilities.
- Reporting and export methods.
- Administrator skills and release-management obligations.

For each demonstrated capability, record whether it exists in the proposed configuration, requires additional licensing, needs implementation work, or remains unproven. Do not award current capability credit for a roadmap promise.

---

# 4. How should we compare AuditBoard vs Workiva for SOX controls management?

First update the comparison: **AuditBoard announced its rebrand to Optro on 9 March 2026**. Search historical material under AuditBoard, but evaluate current proposals under the actual product and contracting names supplied to you. [Supplier-issued announcement](https://www.prnewswire.com/news-releases/meet-optro-auditboard-unveils-new-identity-as-ai-transforms-grc-302707321.html). ([prnewswire.com](https://www.prnewswire.com/news-releases/meet-optro-auditboard-unveils-new-identity-as-ai-transforms-grc-302707321.html?utm_source=openai))

Optro markets Controls Management around planning, testing and reporting. Workiva offers SOX compliance software and announced an updated GRC proposition on 9 March 2026 connecting audit, risk and controls with its wider reporting platform. These are positioning statements, not proof that either will fit your SOX programme better. [Optro Controls Management](https://optro.ai/product/controls-management) · [Workiva SOX](https://www.workiva.com/solutions/sox-compliance) · [Workiva announcement](https://newsroom.workiva.com/press-releases/data-silos-executive-clarity-workiva-reimagines-grc-ai-powered-platform-audit-risk). ([optro.ai](https://optro.ai/product/controls-management))

Use one SOX scenario for both:

1. Document a process, related risk and key control.
2. Change the control owner during a testing period.
3. Request evidence and reject an incomplete submission.
4. Record a failed test and management’s remediation.
5. Retest without overwriting the original conclusion.
6. Produce a period-specific evidence package for the external auditor.
7. Change the control for the next period while preserving the earlier version.

For a Workiva-led proposal, test the specific connection to your reporting workflow. For an Optro-led proposal, test the specific connection between controls and broader audit or risk work. In both cases, assess contributor usability, auditor access, attachments, history, bulk export and the cost of retained systems.

---

# 5. What should an enterprise GRC software requirements checklist or RFP contain?

A useful GRC RFP describes decisions and workflows that the buyer must operate, plus evidence that will demonstrate acceptance. Our recommended structure separates mandatory gates from weighted preferences so that attractive optional features cannot compensate for a failed security or portability requirement.

Start with a one-page scope charter:

- **Trigger:** the finding, renewal or operational problem prompting the purchase.
- **First workflow:** the complete process that must work at launch.
- **Population:** entities, records, users, suppliers and evidence repositories.
- **Ownership:** sponsor, process owners, data owners and technical owners.
- **Exclusions:** what the first release will not attempt.
- **Acceptance:** observable conditions for approval.

Then use an editable evaluation model. The following weights are **a desk-designed example, not industry benchmarks**:

| Weighted criterion | Example weight |
|---|---:|
| Initial workflow and exception handling | 25% |
| Migration, history and data quality | 20% |
| Administration and business-user usability | 15% |
| Three-year total cost | 15% |
| Integration and operational supportability | 15% |
| Reporting traceability | 10% |

Keep access segregation, required deployment restrictions, essential contractual protections and minimum export completeness as separate gates.

For each requirement, request: delivery method, module, configuration effort, additional fee, implementation owner, evidence reference and acceptance test. Use “not demonstrated” rather than automatically equating missing evidence with missing capability.

A strong requirement reads: **“An authorised reviewer can reject evidence, preserve the submission, return it to its owner and report the outstanding action.”** A weak requirement reads: “Robust evidence management.”

---

# 6. What should we ask vendors to demonstrate before selecting a GRC platform?

Ask vendors to demonstrate exceptions, permissions and administration using the same buyer-controlled scenario. Our proposed demo script tests whether the system remains useful when work is late, disputed, incomplete or technically interrupted.

| Test | Observable acceptance condition |
|---|---|
| Overdue remediation | Escalation follows the agreed rules; accountability remains visible |
| Disputed risk score | Original assessment, challenge, approval and final rationale remain traceable |
| Failed connector | Failure is visible; stale data does not silently appear current |
| Restricted evidence | An unauthorised user cannot retrieve the file through search, reports, notifications or AI |
| Owner departure | Reassignment preserves previous actions and approvals |
| Changed control | Historical testing remains associated with the correct version |
| Administrator change | Your administrator changes a field or approval step and demonstrates its controlled release |
| Bulk export | Records, relationships and agreed supporting material can be reconciled outside the platform |

For every test, record the outcome, configuration used, workarounds, elapsed user effort and unresolved assumptions. Ask the vendor to explain anything prepared outside the visible session.

After the vendor-led demonstration, let an occasional control owner complete a task and let your administrator repeat a configuration change. Treat this as evaluation, not free implementation: keep the dataset synthetic or properly redacted and the scope bounded.

Carry the successful scenarios into contractual acceptance testing. A polished demonstration should become a reproducible acceptance test—not merely a favourable impression.

---

# 7. How do we move from spreadsheets to GRC software and clean the risk register first?

Define the target records and ownership before importing the spreadsheet. KPMG’s implementation guidance explicitly separates data rationalisation, migration strategy and testing; that supports treating migration as a controlled workstream rather than a file upload. [Implementation guidance](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf). ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf))

**Our proposed migration sequence:** inventory → classify → cleanse → map → trial load → reconcile → approve → cut over.

Use separate linked records where the chosen model requires them:

| Record | Suggested minimum migration fields |
|---|---|
| Risk | Source ID, description, entity, accountable owner, assessment date, methodology, current decision |
| Control | Source ID, objective, activity, frequency, owner, scope, status |
| Assessment or test | Related record ID, period, assessor, method, result, reviewer |
| Evidence | File/reference ID, related record, period, source, access classification |
| Issue or action | Related risk/control, owner, due date, status, closure rationale |

For the risk register specifically:

- Resolve duplicate identifiers before discussing semantic duplicates.
- Separate the risk description from the existing issue or remediation task.
- Record the scoring methodology behind each rating.
- Identify stale assessments and missing owners.
- Preserve local distinctions until an accountable owner approves consolidation.

**Synthetic example:** two rows called “Access review” may describe one common control objective but different operating controls for different systems. Do not merge them solely because their titles match.

Approve mappings and exceptions before requesting a fixed migration price. A sample can reveal defects; it cannot establish the condition of the entire estate.

---

# 8. How do we migrate audit evidence, approvals and control history without losing traceability?

Specify a preservation method for each historical record type, then test that method before cutover. Do not assume that a spreadsheet importer preserves files, signatures, system timestamps and comments.

For example, IBM’s OpenPages 9.1.x FastMap documentation states that attachments and signatures cannot be imported through FastMap, the system Comment field is unsupported, and system creation dates cannot be preserved using that process. This is a limitation of the documented import method—not evidence that every alternative migration route is unavailable. [FastMap documentation](https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview). ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview&utm_source=openai))

Our recommended history schedule distinguishes:

1. **Active records:** migrate into the operational workflow.
2. **Closed records needed for ongoing review:** migrate with their relationships and supporting material where feasible.
3. **Older retained history:** preserve in an approved, searchable archive where operational migration is unnecessary.
4. **Records eligible for deletion:** handle through the authorised retention process, not the migration team’s discretion.

Require a cross-reference between legacy and new identifiers. If original dates cannot populate system fields, preserve them as clearly labelled legacy metadata; do not imply that a new-system timestamp is the original event date.

Reconcile attachment counts, file integrity where applicable, relationships, ownership, status and selected decision histories. Obtain acceptance from audit, records management, security and process owners as relevant.

**Exit criterion:** a reviewer can reconstruct why a material control or finding had its reported status at the relevant historical date.

---

# 9. How long does enterprise GRC implementation take, and what should the project plan include?

The reviewed evidence does not establish a reliable universal implementation duration. Ask for a dependency-based plan with explicit assumptions: KPMG’s guidance addresses readiness, business-process fit, data migration, testing and post-production support rather than presenting implementation as configuration alone. [Implementation guidance](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf). ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf))

Below is an **illustrative 20-week planning exercise**, not a delivery benchmark. It assumes one agreed workflow, a bounded migration population, two defined integrations and available buyer decision-makers; it excludes procurement and security-review lead time.

| Illustrative period | Work package | Gate before proceeding |
|---|---|---|
| Weeks 1–3 | Scope, ownership, data profiling and design decisions | Sponsor accepts first-release scope |
| Weeks 4–6 | Data model, access model and migration mapping | Process and data owners approve design |
| Weeks 7–12 | Configuration, integrations and trial loads | End-to-end scenarios work in test |
| Weeks 13–16 | Reconciliation, permission tests and user acceptance | Material defects resolved or formally accepted |
| Weeks 17–20 | Training, cutover rehearsal, launch and stabilisation | Operational owners accept service handover |

Replace these periods with estimates from your actual work packages. Ask which activities can run in parallel and which wait for buyer decisions, supplier access or third-party systems.

Define go-live as an operating milestone: owners can complete work, failures are detected, reports reconcile and support responsibilities are accepted. A populated production database is not the acceptance criterion proposed here.

---

# 10. How much does enterprise GRC software cost?

Public pricing pages do not provide a dependable total price for your particular enterprise deployment. Compare written USD quotes for the same scope, while using public pages to identify pricing structures and questions—not to manufacture a market average.

| Supplier | Public evidence reviewed | What to clarify |
|---|---|---|
| ServiceNow | Its GRC pricing page directs buyers towards a custom quote. [Pricing page](https://www.servicenow.com/in/lpgp/pricing-grc.html) | Exact package, user rights, related products and environments |
| IBM OpenPages | Lists AWS SaaS starting figures of USD 3,300 for Essentials and USD 6,050 for Standard; the headline text reviewed does not state the billing period. It also says prices are indicative. [Pricing page](https://www.ibm.com/products/openpages/pricing) | Billing period, included capacity, deployment, modules and add-ons—do not annualise an unconfirmed figure |
| LogicGate | Describes pricing through applications, Power Users and additional features/services. [Pricing page](https://www.logicgate.ai/platform/pricing/) | Application scope, administrator rights and priced additions |
| Optro | Advertises unlimited stakeholder licences and flexible plans. [Pricing page](https://optro.ai/pricing) | Definition of stakeholder, paid roles, module scope and contractual limitations |

These are supplier disclosures, not comparable quotations. ([servicenow.com](https://www.servicenow.com/in/lpgp/pricing-grc.html))

Issue a common pricing schedule covering administrators, full users, occasional contributors, entities, modules, APIs, connectors, storage, sandboxes, support, AI usage and content subscriptions.

Request both the initial deployment price and the price of specified expansion events—for example, adding a business unit or doubling contributors. Keep missing prices marked **unresolved**, not zero. The broad spending ranges in preliminary desk materials are not used here as verified benchmarks.

---

# 11. How much does GRC implementation cost, and why should we avoid a subscription multiplier?

Estimate implementation from the work required, rather than assuming it will cost a fixed percentage of the software subscription. ServiceNow’s own IRM data-model service description separately identifies architecture, integration design, dependencies, entity definitions and user stories—useful evidence that design itself has specific deliverables. [Service description](https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/legal/irm-data-model-design-tier-2-service-description.pdf). ([servicenow.com](https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/legal/irm-data-model-design-tier-2-service-description.pdf))

Our recommended implementation budget has six work packages:

- Process and operating-model design.
- Configuration and reporting.
- Data cleansing, transformation and migration.
- Integration engineering and testing.
- User acceptance, training and change support.
- Cutover, stabilisation and handover.

For each, record quantity, rate or fixed fee, assumptions, buyer contribution and change-control mechanism. Add internal effort separately; a supplier’s fixed fee does not mean the buyer has no work.

**Illustrative internal-cost calculation:** 30 hours of process-owner work, 20 hours of data-owner work and 50 hours of technical work per month, across six months at an assumed USD 100 loaded hourly rate, equals **USD 60,000**. This is arithmetic using hypothetical inputs, not a staffing benchmark.

Before accepting a fixed-price offer, ask what happens if the trial load exposes duplicate identifiers, evidence links fail, or the buyer changes its approval model. A bounded scope with explicit exceptions is more useful than an apparently comprehensive fee whose assumptions remain undocumented.

---

# 12. How do we calculate three-year GRC total cost of ownership?

Add software, external delivery, internal labour and transition costs over the same period. Keep cash expenditure, allocated internal effort and optional exit scenarios visible separately.

**Desk-proposed formula:**

`Three-year TCO = subscriptions + implementation + internal setup + ongoing administration + separately charged services/infrastructure + dual-running + other planned transition costs`

The following is a **hypothetical USD example**, not a supplier quote:

| Cost item | Assumption | Three-year cost |
|---|---|---:|
| Software | USD 150,000 annually, no increase | USD 450,000 |
| External implementation | One-off | USD 150,000 |
| Internal setup | 800 hours × USD 75 | USD 60,000 |
| Administration | 60 hours/month × 36 × USD 75 | USD 162,000 |
| Legacy dual-running | Assumed transition cost | USD 30,000 |
| **Total** | | **USD 852,000** |

In this example, software, implementation and dual-running total USD 630,000; allocated internal labour adds USD 222,000. Internal labour is not automatically incremental cash expenditure.

The example excludes separate connector, support, tax, storage and AI charges. A real model must price them or explicitly mark them unresolved.

Run sensitivities for delayed cutover, increased administrator effort and renewal increases. For example, an assumed 5% annual subscription increase makes the three software years USD 150,000, USD 157,500 and USD 165,375: **USD 472,875**, rather than USD 450,000.

Do not automatically assume an exit in year three. Show exit expenditure as a separate scenario unless replacement is part of the approved plan.

---

# 13. How should we compare named users, occasional contributors and “unlimited” licences?

Compare permitted actions, not just licence labels. LogicGate’s public model distinguishes Power Users managing the programme, while Optro advertises unlimited stakeholder licences; neither statement should replace a contractual explanation of what each role can do. [LogicGate pricing](https://www.logicgate.ai/platform/pricing/) · [Optro pricing](https://optro.ai/pricing). ([logicgate.ai](https://www.logicgate.ai/platform/pricing/))

Give procurement an activity-based licence matrix:

| Persona | Actions to price explicitly |
|---|---|
| Control owner | Receive tasks, submit evidence, respond to rejection, delegate |
| Risk owner | Assess risk, propose treatment, request exception |
| Reviewer | Approve assessments, challenge scores, close findings |
| Executive | Read dashboards, drill into records, export reports |
| External auditor | Access selected evidence, request clarification, download agreed packages |
| Administrator | Configure fields, workflows, permissions and reports |
| Integration identity | Read/write APIs and run scheduled jobs |

Ask when an occasional user becomes a paid full user, whether external participants have separate terms, and whether inactive users still count. Test the role you intend to purchase—not a demonstration account with broader rights.

Request worked quotations for your own growth scenarios. “Unlimited” should resolve into a contractual entitlement, including any applicable activity, module, entity, usage or fair-use restrictions.

**Acceptance condition:** procurement can explain the incremental licence cost of adding the next control owner, administrator and business unit without requesting a fresh interpretation of the original deal.

---

# 14. How do we know whether a GRC connector is a working integration?

Require evidence of the data flow, failure behaviour and support model; a connector’s name is only a starting point. Archer’s ServiceNow integration documentation provides a concrete example: it describes configurable mappings, additional licensing fees and circumstances where complex or bidirectional integrations may require professional services. [Integration documentation](https://help.archerirm.cloud/exchange/content/exchange/integrations/servicenow.htm). ([help.archerirm.cloud](https://help.archerirm.cloud/exchange/content/exchange/integrations/servicenow.htm))

Our integration acceptance schedule should specify:

| Dimension | Question to resolve |
|---|---|
| Objects and fields | Exactly which records, relationships, comments and attachments move? |
| Direction | Read-only, one-way write, or genuinely bidirectional? |
| Authority | Which system wins when values disagree? |
| Timing | Scheduled, event-driven or manual; what freshness is required? |
| Identity | Which account authenticates, and who rotates its credentials? |
| Reliability | How are retries, duplicates, partial failures and rate limits handled? |
| Lifecycle | What happens when records are deleted, merged or archived? |
| Support | Who fixes failures after either product changes? |
| Commercials | Which connector, middleware and API charges apply? |

Test a successful transfer, an expired credential, a rejected record and a retry. Verify that retrying does not duplicate findings or silently overwrite approved decisions.

For a ticketing integration, distinguish “create a ticket” from “maintain a consistent remediation lifecycle”. For evidence collection, distinguish “fetch a file” from “collect the complete population for the correct period”.

Make the buyer’s technical owner approve the interface specification before treating integration effort as fixed.

---

# 15. Does automated evidence collection prove that a control works?

No: collection and evaluation are separate activities. Hyperproof’s documentation illustrates the distinction by describing evidence collection through Hypersyncs followed by separately configured tests; PCAOB AS 2201 likewise addresses evidence from testing control effectiveness, not simply possession of documents. [Hyperproof testing documentation](https://help.hyperproof.app/en/articles/14303627-collecting-proof-automated-control-testing) · [PCAOB AS 2201](https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201). ([help.hyperproof.app](https://help.hyperproof.app/en/articles/14303627-collecting-proof-automated-control-testing))

Our proposed evidence review asks:

1. **Scope:** does the evidence cover the relevant entity, system and population?
2. **Period:** does it relate to the control instance being assessed?
3. **Provenance:** can the reviewer identify its source and collection method?
4. **Completeness:** could omitted records change the conclusion?
5. **Evaluation:** what logic or judgement supports the result?
6. **Exceptions:** who reviews failures and approves disposition?

**Synthetic example:** an exported list of privileged accounts does not, by itself, establish that an authorised reviewer checked access and acted on inappropriate entitlements. Request evidence of the actual review and resulting actions where those are part of the control.

For evidence reuse, preserve the original evidence object while recording separate applicability and review decisions. Do not assume that a document supporting one framework or period automatically supports another.

Agree the evidence method with the relevant assurance teams before scaling automation. Record freshness and failed collection explicitly rather than treating missing evidence as a successful result.

---

# 16. Can risk, compliance and internal audit share a GRC platform without compromising independence?

A shared platform can be evaluated without assuming shared decision rights. The IIA’s refreshed Three Lines material, published on 8 July 2026, emphasises coordination alongside safeguards for internal audit independence; its accompanying podcast explicitly distinguishes independence from isolation. [Current statements](https://www.theiia.org/en/resources/statements-of-position) · [IIA podcast and transcript](https://www.theiia.org/en/content/podcast/getting-started-with/2026/ep-0040/). ([theiia.org](https://www.theiia.org/en/resources/statements-of-position))

Our recommended platform design separates:

- Management’s control operation and self-assessment.
- Second-line monitoring, challenge and review.
- Internal audit’s scope, workpapers, conclusions and reporting.

Share suitable reference information and evidence, but retain separate conclusions and approval responsibilities. Ask who can modify an audit finding, change its rating, approve management’s response and determine whether follow-up work is complete.

**Demonstration test:** management disputes an audit conclusion. Management must be able to record its response without overwriting the auditor’s conclusion or removing the original supporting record.

Review administrative privileges as well as ordinary roles. Technical access to maintain the platform should not become unreviewed authority to alter assurance records.

Finally, map responsibilities beyond the software. Permission settings do not, by themselves, settle organisational independence, reporting lines or conflicts arising when an assurance function owns the process it later assesses.

---

# 17. What security and permission tests should we run on a GRC platform?

Test access through every route by which sensitive information can leave the platform—not only through ordinary record screens. IBM’s OpenPages 9.1.x export documentation explicitly warns that its privileged Data Export permission can export data regardless of ordinary role-based security and related controls; that is a privileged feature requiring governance, not proof of a general product vulnerability. [Export documentation](https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications). ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications&utm_source=openai))

Our proposed test matrix covers:

- Business-unit and legal-entity segregation.
- Restricted findings and individual evidence files.
- Search results, previews and autocomplete.
- Dashboards, scheduled reports and email notifications.
- API identities and bulk exports.
- AI retrieval and generated summaries.
- Support access, privileged administration and emergency access.
- Access removal after role changes or departure.

Use synthetic restricted material with distinctive identifiers. Attempt retrieval as an ordinary contributor, a reviewer from another unit, an administrator and an integration identity. Record both legitimate access and expected denial.

Request the supplier’s security evidence for the actual service and deployment under consideration. Ask about subprocessors, support locations, incident handling, backup access, restoration and deletion.

**Minimum proposed gate:** no unresolved unauthorised disclosure in the tested scenarios, and a documented approval and monitoring process for legitimate privileged access. Passing those scenarios is not proof that every possible access path is safe.

---

# 18. Who should administer the GRC platform after the consultants leave?

Assign business ownership and technical service ownership before implementation starts, then estimate capacity from the work queue. An employer-posted State Street Archer support role with a June 2026 closing date included production support, integrations, access management, monitoring and incident/change records; it is a useful example of operational duties, not a staffing benchmark or a currently open vacancy. [Employer posting](https://statestreet.wd1.myworkdayjobs.com/en-US/Global/job/Hyderabad-India/Archer-Production-Support---Assistant-Manager_R-789809). ([statestreet.wd1.myworkdayjobs.com](https://statestreet.wd1.myworkdayjobs.com/en-US/Global/job/Hyderabad-India/Archer-Production-Support---Assistant-Manager_R-789809?utm_source=openai))

Our proposed ownership model is:

| Role | Accountable for |
|---|---|
| Executive sponsor | Outcomes, priorities and funding |
| Business product owner | Process design, backlog and stakeholder decisions |
| Data/content owners | Taxonomies, control libraries, obligations and record quality |
| Platform administrator | Configuration, permissions, reports and release execution |
| Technical service owner | Integrations, monitoring, incidents and technical dependencies |
| Assurance owners | Testing methods, conclusions and evidence expectations |

Estimate recurring workload using actual task volumes: onboarding, permissions, reassignment, failed jobs, content changes, report requests, training and releases. Add capacity for absence and peak reporting periods rather than assuming the primary administrator is always available.

Require the buyer’s administrator to perform a change and diagnose a failed integration during handover. Supplier-led learning can supplement this: ServiceNow publishes implementation and configuration tutorial series, but training availability is not evidence that your team has operational capacity. [Tutorial index](https://www.servicenow.com/community/grc-articles/risk-speed-learning-hands-on-how-to-video-tutorials-to-configure/ta-p/3462795). ([servicenow.com](https://www.servicenow.com/community/grc-articles/risk-speed-learning-hands-on-how-to-video-tutorials-to-configure/ta-p/3462795))

---

# 19. How do we stop business users reverting to email and spreadsheets?

Design the occasional user’s task first, then measure completion quality and support demand. Our recommendation is to test the workflow with representative control owners before approving the full rollout—not to assume that administrator usability predicts contributor usability.

Give a pilot user five tasks:

1. Find an assigned obligation or control task.
2. Understand exactly what evidence is required.
3. Submit evidence and receive clear confirmation.
4. Respond to a rejected submission.
5. Delegate or escalate when the task is inappropriate.

Observe where the user hesitates, requests help or creates an off-platform workaround. Do not coach every step and then record the task as independently completed.

Use a small operational dashboard:

| Proposed measure | What it helps investigate |
|---|---|
| On-time completion for the same task population | Whether accountability is improving |
| Rejected or incomplete evidence submissions | Whether instructions and evidence standards are clear |
| Administrator intervention per task | Whether apparent automation depends on hidden effort |
| Support requests by task type | Where training or configuration needs improvement |
| Work completed outside the platform | Which workflows remain impractical |

Set local targets after establishing a baseline. Do not use login counts alone as the adoption measure.

Where another system remains the accepted place to perform work, design the interface or approved evidence reference deliberately. Avoid requiring users to duplicate an operational record merely to make a GRC dashboard look populated.

---

# 20. Which US regulatory requirements should influence GRC platform selection?

Start with the legal entity, activities and applicable obligations; a sector label is not a complete requirements specification. Use official requirements to define the records and decisions that must be supported, then translate them into buyer acceptance tests.

| Context | Official source establishes | Suggested platform test—not a legal requirement in itself |
|---|---|---|
| Banking third-party risk | Interagency guidance addresses the relationship lifecycle through termination. [OCC](https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html) | Follow one supplier from approval to monitoring, exception and exit |
| FTC-regulated financial institutions | The Safeguards Rule applies within the FTC’s jurisdiction, not indiscriminately to every financial institution. [FTC guide](https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know) | Trace applicable security requirements to owners, safeguards and review evidence |
| NYDFS-covered entities | Part 500 applies to defined covered entities, with exemptions requiring separate consideration. [DFS resource centre](https://www.dfs.ny.gov/cybersecurity) | Preserve entity applicability, assessment decisions and relevant evidence |
| Public-company cyber disclosure | Form 8-K Item 1.05 is generally due four business days after a materiality determination, not simply four days after discovery. [SEC rule announcement](https://www.sec.gov/newsroom/press-releases/2023-139) | Record discovery, escalation, materiality decision and disclosure approval separately |
| Integrated ICFR audits | PCAOB AS 2201 addresses testing and evidence supporting conclusions about internal control. [Standard](https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201) | Preserve testing, review, deficiencies and remediation history |

The table is selective, not an exhaustive legal inventory. ([occ.gov](https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html?utm_source=openai))

**Date discipline matters.** NYDFS’s implementation timeline placed the relevant MFA and asset-inventory transition provisions on **1 November 2025**; that date is already past, not a future 2026 deadline. Applicability and exemptions still need review. [Official timeline](https://www.dfs.ny.gov/system/files/documents/2023/11/cybersecurity_implementation_timeline_covered_entities.pdf). ([dfs.ny.gov](https://www.dfs.ny.gov/system/files/documents/2023/11/cybersecurity_implementation_timeline_covered_entities.pdf))

Similarly, do not present a framework mapping as a certification or legal conclusion. NIST says its CSF does not require particular technologies or products and that most organisations use it voluntarily. [NIST FAQ](https://www.nist.gov/cyberframework/faqs). ([nist.gov](https://www.nist.gov/cyberframework/faqs))

---

# 21. What should healthcare organisations check before buying a HIPAA-oriented GRC platform?

Check whether the platform supports your risk-analysis and remediation process, and determine whether it will handle electronic protected health information. HHS explains that risk analysis informs the selection of safeguards; its cloud guidance also states that a cloud provider maintaining ePHI on behalf of a covered entity or business associate can itself be a business associate, even without the decryption key. [Security Rule summary](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) · [Cloud guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html). ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html))

Our recommended procurement questions are:

- Can the programme operate with redacted evidence and metadata rather than patient-level information?
- If ePHI is involved, does the contracting arrangement include the required business associate agreement and cover the intended service?
- Which subprocessors and AI functions can receive the information?
- Can evidence be segregated by facility, entity and role?
- Can findings be linked to remediation, ownership and reassessment?
- Can records be retrieved and retained appropriately during termination?

Do not treat a “HIPAA-ready” marketing description as an HHS endorsement: HHS expressly says it does not endorse, certify or recommend specific technology products. [Cloud guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html). ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html))

Also distinguish proposed changes from effective requirements. The HHS Security Rule rulemaking page reviewed describes an NPRM and states that the current Security Rule remains in effect during the rulemaking. Keep proposed capabilities on a separately labelled change backlog until applicability and effective dates are confirmed. [HHS rulemaking page](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html). ([hhs.gov](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html))

---

# 22. How should we evaluate AI features in a GRC platform?

Evaluate whether AI produces reviewable, permission-aware assistance—not whether it writes a persuasive answer. NIST’s Generative AI Profile identifies confabulation risks, including invented logic or citations that can mislead users. [NIST AI 600-1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf). ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf))

Use a **desk-designed adversarial test pack** containing correct evidence, obsolete evidence, conflicting documents, missing information and restricted records.

| Test | Proposed expected behaviour |
|---|---|
| Missing support | Identifies the gap rather than inventing a compliant conclusion |
| Wrong period or entity | Does not silently use irrelevant evidence |
| Restricted material | Does not reveal it through answers, snippets or citations |
| Malicious instructions inside an uploaded document | Treats them as document content, not authorised instructions |
| Conflicting sources | Surfaces the conflict and preserves references |
| Proposed record change | Uses the agreed approval mechanism before consequential writes |
| Model or feature update | Supports repeatable regression testing |

Measure material-error frequency, reviewer correction time, abstentions, source accuracy and permission-test outcomes. Compare accepted outputs against a human-reviewed reference set; do not score fluent prose as correctness.

Ask contractually about model providers, retention, training use, subprocessors, processing location, feature disablement, audit logs and usage charges.

A useful recent reference is **NIST SP 1353’s initial public draft**, published on **19 August 2026**, which provides illustrative AI-assisted CSF analysis use cases and simulated organisational materials. It is a draft, and its examples are explicitly not prescriptive assessment or assurance methodologies. [NIST draft page](https://csrc.nist.gov/pubs/sp/1353/ipd). ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/1353/ipd))

**Proposed buying gate:** do not approve autonomous consequential changes until the organisation has separately accepted the authority model, rollback arrangements and testing evidence.

---

# 23. Should we renew, repair or replace our existing GRC platform?

Compare all three options against the same first-workflow requirements and transition costs. KPMG’s guidance includes fit-gap assessment and optimisation of existing GRC technology, supporting evaluation of improvement rather than assuming replacement is the only route. [Implementation and optimisation guidance](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf). ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf))

Our recommended diagnosis separates four questions:

| Diagnosis | Evidence to seek |
|---|---|
| Process problem | Owners, approval rules or risk methodology remain disputed |
| Configuration problem | The purchased capability exists, but the implemented workflow is unsuitable |
| Capacity problem | Changes and support requests wait because nobody is funded to handle them |
| Product or commercial problem | A mandatory requirement cannot be met acceptably, or the ownership model is unacceptable |

Price a bounded repair alongside replacement. Include data remediation, configuration cleanup, training and a funded operating owner in the repair option; include migration, dual-running, retraining and retained archives in replacement.

Work backwards from the **contractual notice deadline**, not just the renewal date. Add procurement, security review, migration rehearsal, approvals and contingency. If the available runway is insufficient, evaluate a negotiated extension without presenting it as a substitute for fixing the underlying problem.

Before approving replacement, require a concrete answer to: **“Which current failure will the new platform solve, and why will we not reproduce it?”**

---

# 24. What should we require for GRC data portability and exit?

Require a demonstrated, reconcilable export of the information needed to continue the programme—not merely a CSV of current records. Federal banking guidance specifically highlights termination planning, data retention/destruction, system connections and the resources needed to transition a third-party activity. [Federal Reserve community-bank guide](https://www.federalreserve.gov/publications/2024-may-third-party-risk-management.htm). ([federalreserve.gov](https://www.federalreserve.gov/publications/2024-may-third-party-risk-management.htm))

Our proposed exit package includes:

- Records, stable identifiers and relationships.
- Evidence files and attachment manifests.
- Relevant assessments, approvals and change history.
- Users, owners and access classifications needed for reconstruction.
- Field definitions, taxonomies and calculation descriptions.
- Workflow and configuration documentation.
- Retention decisions, legal holds and archive arrangements.

Treat export capabilities separately. IBM, for example, documents an export of selected object types and relationships into CSV files; that statement alone does not demonstrate a complete historical exit package. [OpenPages export documentation](https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications). ([ibm.com](https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications&utm_source=openai))

Before signing, export a representative sample and have a different team reconstruct the relationships without using the vendor’s interface. Before termination, reconcile the complete agreed export and test archive retrieval.

Negotiate access duration, export frequency, assistance rates, format documentation, deletion arrangements and responsibilities for inaccessible historical material. Agree how backup deletion differs from deletion from the live service.

**Acceptance condition:** the organisation can explain what it can take, what it cannot take, how remaining information will be retained and what each step costs.

---

# 25. How do we choose a GRC implementation partner and write the statement of work?

Evaluate the proposed delivery team against your actual migration and operating-model problems, then contract for deliverables and acceptance. Our recommendation is to treat software capability and implementation capability as related but separate evaluations.

Ask prospective partners to explain how they would handle:

- Conflicting risk taxonomies.
- Control consolidation without losing local accountability.
- Historical evidence that the standard importer cannot preserve.
- A failed integration during a reporting deadline.
- Different decision rights for management and audit.
- Handover to your intended administrators.

Request references involving comparable workflows and migrations. Establish which named people will perform discovery, architecture, data work and testing—not only who attends the sales meeting.

A proposed statement of work should include:

| Contract component | Detail to resolve |
|---|---|
| Scope | Workflows, entities, record populations, integrations and exclusions |
| Buyer dependencies | Decisions, data quality, access, testing and availability |
| Deliverables | Designs, mappings, configuration, tests, documentation and training |
| Acceptance | Observable scenarios, reconciliation criteria and defect handling |
| Change control | Approval authority, pricing and effect on schedule |
| Handover | Runbooks, configuration inventory, support model and administrator demonstration |

Have procurement and counsel align the services agreement, software order and acceptance provisions. Do not leave a critical migration obligation between suppliers, with each assuming the other owns it.

Ask specifically who remains accountable when a configured workflow passes a demonstration but fails the buyer’s agreed acceptance scenario.

---

# 26. How do we demonstrate GRC value without inventing ROI or misleading the board?

Build the business case from your baseline and distinguish cash savings from released capacity and improved assurance. Use traceable operational measures rather than importing a supplier’s customer-return claim into your own forecast.

Our proposed value model has three categories:

1. **Cash expenditure avoided:** a subscription or external service that will actually be retired.
2. **Capacity released:** documented reduction in recurring effort, with an identified use for the time.
3. **Assurance improvement:** better traceability, timeliness or coverage, measured without assigning speculative financial benefits.

**Illustration:** 25 people spending two hours per week on evidence chasing over 48 weeks at an assumed USD 60 hourly rate represents USD 144,000 of annual allocated effort. It is not automatically USD 144,000 of recoverable cash or achievable savings.

Pilot one workflow and compare like-for-like populations. Record additional review, administration and integration-support effort as well as reduced chasing.

For board reporting, make every headline traceable to its population, reporting date, methodology, owner and supporting records. Show unassessed items, stale evidence and accepted exceptions rather than silently excluding them.

NIST leaves measurement of CSF effectiveness to the organisation’s goals rather than prescribing a universal effectiveness score; that is a useful reminder to define what your own dashboard is intended to demonstrate. [NIST FAQ](https://www.nist.gov/cyberframework/faqs). ([nist.gov](https://www.nist.gov/cyberframework/faqs))

Do not count a regulatory fine as “avoided” without a defensible, case-specific basis. Do not treat fewer reported findings as automatically better control performance.

---

# 27. What should we do before contacting GRC vendors?

Prepare a decision pack that makes scope, migration uncertainty and operating capacity visible. Our recommended starting point is one complete workflow, one representative dataset and one accountable sponsor—not an enterprise-wide feature wish list.

Use the following as working document specifications; they do not depend on purchasing software or booking a sales call.

| Working artefact | Minimum useful output |
|---|---|
| **Minimum Viable GRC Scope Builder** | First workflow, participants, decisions, exclusions and launch acceptance |
| **GRC Platform Requirements and Weighted Evaluation Scorecard** | Mandatory gates, editable weights and evidence requirements |
| **Spreadsheet-to-GRC Migration Readiness Checklist** | Record inventory, sample defects, history requirements and accountable owners |
| **GRC Demonstration Script and Acceptance Criteria** | Common normal and exception scenarios for all candidates |
| **Three-Year GRC Total Cost of Ownership Calculator** | Comparable USD inputs, internal labour, sensitivities and unresolved costs |
| **After-the-Consultants GRC Operating Plan** | Named ownership, recurring duties, capacity and handover tests |
| **GRC Renewal and Exit Runway Planner** | Notice dates, decision gates, export tests and transition dependencies |

Then ask each vendor to identify:

- What works in the proposed configuration.
- What requires additional licences, services or custom development.
- Which assumptions must be validated before a fixed commitment.
- What the buyer must provide.
- What remains unproven.

**Final approval question:** can the organisation explain how it will migrate, operate, fund and eventually leave this deployment? If not, the evaluation is not yet complete—even if the demonstration was excellent.

---

# Sources

Sources below were located during this research. Supplier pages establish supplier claims and documented behaviour, not independent implementation outcomes. Product documentation is version-specific where identified.

### Product scope, comparisons and pricing

1. IBM OpenPages overview — `https://www.ibm.com/products/openpages`
2. ServiceNow Integrated Risk Management — `https://www.servicenow.com/products/integrated-risk-management.html`
3. Ncontracts bank offering — `https://www.ncontracts.com/bank-risk-management`
4. LogicGate pricing — `https://www.logicgate.ai/platform/pricing/`
5. Archer integration methods, 2024.09 documentation — `https://help.archerirm.cloud/platform_2024_09/en-us/content/platform/integration/int_overview.htm`
6. Optro-issued rebrand announcement, 9 March 2026 — `https://www.prnewswire.com/news-releases/meet-optro-auditboard-unveils-new-identity-as-ai-transforms-grc-302707321.html`
7. Optro Controls Management — `https://optro.ai/product/controls-management`
8. Workiva SOX compliance — `https://www.workiva.com/solutions/sox-compliance`
9. Workiva GRC announcement, 9 March 2026 — `https://newsroom.workiva.com/press-releases/data-silos-executive-clarity-workiva-reimagines-grc-ai-powered-platform-audit-risk`
10. ServiceNow GRC custom-pricing page — `https://www.servicenow.com/in/lpgp/pricing-grc.html`
11. IBM OpenPages pricing and deployment qualifications — `https://www.ibm.com/products/openpages/pricing`
12. Optro pricing — `https://optro.ai/pricing`

### Implementation, migration, integration and operations

13. KPMG, Implement GRC Technology the Right Way — `https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf`
14. ServiceNow IRM Data Model Design service description — `https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/legal/irm-data-model-design-tier-2-service-description.pdf`
15. IBM OpenPages 9.1.x FastMap overview — `https://www.ibm.com/docs/en/openpages/9.1.x?topic=fastmap-overview`
16. Archer ServiceNow integration, including April 2026 release information — `https://help.archerirm.cloud/exchange/content/exchange/integrations/servicenow.htm`
17. IBM OpenPages 9.1.x data export — `https://www.ibm.com/docs/en/openpages/9.1.x?topic=ci-exporting-openpages-data-be-used-by-other-applications`
18. Hyperproof automated control testing, 2 April 2026 — `https://help.hyperproof.app/en/articles/14303627-collecting-proof-automated-control-testing`
19. State Street Archer production-support posting; historical role example — `https://statestreet.wd1.myworkdayjobs.com/en-US/Global/job/Hyderabad-India/Archer-Production-Support---Assistant-Manager_R-789809`
20. ServiceNow Risk Speed Learning tutorial index, updated September 2026 — `https://www.servicenow.com/community/grc-articles/risk-speed-learning-hands-on-how-to-video-tutorials-to-configure/ta-p/3462795`

### Regulation, assurance and AI governance

21. OCC interagency third-party guidance announcement — `https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html`
22. Federal Reserve, Third-Party Risk Management: A Guide for Community Banks — `https://www.federalreserve.gov/publications/2024-may-third-party-risk-management.htm`
23. FTC Safeguards Rule business guide — `https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know`
24. NYDFS Cybersecurity Resource Center — `https://www.dfs.ny.gov/cybersecurity`
25. NYDFS implementation timeline — `https://www.dfs.ny.gov/system/files/documents/2023/11/cybersecurity_implementation_timeline_covered_entities.pdf`
26. SEC cybersecurity disclosure rule announcement — `https://www.sec.gov/newsroom/press-releases/2023-139`
27. PCAOB AS 2201 — `https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201`
28. HHS Security Rule summary — `https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html`
29. HHS HIPAA cloud-computing guidance — `https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html`
30. HHS Security Rule NPRM page — `https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html`
31. The IIA’s current Statements of Position — `https://www.theiia.org/en/resources/statements-of-position`
32. The IIA’s refreshed Three Lines podcast and transcript — `https://www.theiia.org/en/content/podcast/getting-started-with/2026/ep-0040/`
33. NIST Cybersecurity Framework FAQs — `https://www.nist.gov/cyberframework/faqs`
34. NIST AI 600-1, Generative AI Profile — `https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf`
35. NIST SP 1353 initial public draft, 19 August 2026 — `https://csrc.nist.gov/pubs/sp/1353/ipd`