Principal GRC Operating Model Director — Functional Configuration Stewardship

The mandate

A banking GRC environment contains years of functional customisations whose original rationale and maintenance ownership are no longer consistently documented. Routine support questions return to former implementation specialists because internal teams cannot tell whether a behaviour is an approved requirement, a temporary workaround or an inherited configuration choice. The principal GRC operating model director begins a four-month project on 26 October 2026 to deliver functional stewardship for the selected MetricStream perimeter. Its purpose is maintainability and support handback, not redesign of risk taxonomies, implementation of new modules or a wider audit of technology controls.

By 14 December 2026, the first milestone provides a customisation inventory with rationale, dependencies and an explicit unknowns register. The 29 January 2027 milestone delivers the stewardship model, owner decisions and diagnostic runbooks for agreed configuration families. On 26 February 2027, final delivery supplies tested support exercises and an internal transfer record. The inventory must distinguish an observed behaviour from proof of its intended business purpose; where the rationale cannot be established, the model will assign a review decision rather than invent a justification to make documentation appear complete.

The platform service owner and functional-support head accept each artifact, with risk-domain owners approving the business rationale attributed to them. Inventory items must trace to agreed configuration records and representative observed behaviour. The stewardship design must identify who can explain, authorise a proposed change and assess its functional consequences. Final acceptance requires internal teams to diagnose unseen support cases in a controlled environment using the runbooks, identifying the correct owner and next decision without consultant guidance. Fees are split 30%, 35% and 35% across accepted outputs, independent of later staffing reductions or vendor-contract negotiations.

The sponsor supplies configuration records, approved requirements, support history, a non-production environment and thirteen available contributors. Four days weekly cover Mumbai-led investigation and workshops with the support team. Production configuration changes, contractual disputes with suppliers and new risk-methodology decisions are excluded. Adding modules or materially undocumented configuration families requires a written change order. Engineering retains technical implementation authority; business owners decide functional purpose. The completed model must make support decisions practicable even when the original implementer is unavailable, while acknowledging specialist dependencies that cannot responsibly be eliminated during this bounded engagement.

What you will own

• Construct the inherited-customisation inventory from configuration records, requirements and observed behaviour, distinguishing verified rationale from assumptions repeated in support conversations without an accountable business source.
• Map dependencies for the selected configuration families, identifying shared behaviours whose maintenance cannot be assigned safely to one domain merely because its team raised the latest support request.
• Design the stewardship decision model with functional, business and engineering owners, separating explanation of existing behaviour from authority to approve a proposed change or implement it technically.
• Build diagnostic runbooks around representative support cases, specifying the records and owner questions needed before an internal analyst treats an apparent configuration defect as a confirmed requirement failure.
• Facilitate rationale decisions with risk-domain owners, retaining unknown or obsolete-purpose items for explicit review rather than retrospectively presenting inherited workarounds as approved business policy.
• Test the support model through unseen controlled-environment exercises, recording whether internal teams identify the right dependency and decision route without assistance from the original implementation specialists.
• Transfer the accepted inventory and runbooks with update ownership and review triggers, leaving a maintainable record that can absorb future functional changes without recreating the same knowledge concentration.

Candidate qualifications

• Show deep MetricStream functional delivery or support experience through an inherited configuration you had to understand before recommending action. Explain how you established its intended purpose, dependencies and owner, including an uncertainty you refused to resolve by assumption. Functional certification or equivalent specialist expertise is expected, but a product credential without difficult maintenance judgement will not establish the required standing.
• Bring 22–28 years in banking GRC technology, financial-services transformation or related delivery, with senior project or programme responsibility. Evidence should include practical collaboration with risk-domain users and support teams after implementation. The project needs someone who can distinguish business purpose from technical behaviour and organise a sustainable owner model, rather than merely produce a large catalogue of configuration screenshots.
• Demonstrate diagnostic and transfer methods that reduced dependence on particular specialists. Describe an internal support exercise that exposed missing knowledge, how you repaired the runbook and which dependency appropriately remained external. You must be comfortable documenting unknown rationale and securing the right owner decision without changing production configuration or supplying an unauthorised risk-policy interpretation to accelerate acceptance.
• Evidence bounded consulting execution with agreed records, a controlled test environment and artifact acceptance. Reserve four days weekly for four months and show how you maintained scope when new undocumented areas emerged. Clear facilitation, secure treatment of banking configuration information and practical writing are essential: internal analysts must be able to use the model for the next unfamiliar case without relying on your presence.

Application

Applications for this mandate are received in one way only: through the India Board Terminal's application process. It is automated end to end. Your Executive Passport travels to the mandate holder in its confidential form, your answers to the three questions below are read before anything else in your file, and every stage that follows is recorded on your applications page.

There is no address to write to and no intermediary to call. The mandate holder reads what the Terminal delivers and nothing else, which is what keeps the process the same for every applicant and keeps your name out of it until you release it. Applications close on 8 October 2026. Mandate reference CVU-CON-2026-IND-137.