Building ResolvX: How I Designed and Delivered a Complete Enterprise GRC Program, from Risk Register to Live Trust Center

ResolvX is a fictional cloud-native SaaS fintech company providing AI-powered financial dispute resolution services to enterprise clients. It runs on three AWS environments (EU regions), employs approximately 120 people, and processes sensitive financial records and personally identifiable information subject to GDPR, PCI-DSS, and SOC 2 obligations.

It is also entirely fictional. I built it and then built its entire compliance program from scratch.

This article documents what that means in practice: the eight phases of the program, the specific deliverables each phase produced, the metrics the Q1 2026 internal audit generated, and what the process revealed about what enterprise GRC work actually requires.

Why Build for a Fintech?

The choice of company profile was deliberate. Financial technology represents one of the most complex regulatory environments in which a GRC program can operate by combining information security requirements (ISO 27001), cloud service organization obligations (SOC 2), payment card industry standards (PCI-DSS), and data privacy laws (GDPR for EU-facing operations).

An AI-powered fintech adds a further layer: the auditability of AI model decisions is not a hypothetical future concern. It is already a regulatory expectation under GDPR's Article 22 (automated decision-making), and an emerging requirement under the EU AI Act for high-risk financial AI systems.

Building ResolvX's GRC program meant confronting all of these obligations simultaneously which is exactly what a compliance officer at a real fintech company would face.

Program Architecture: 8 Phases, 30+ Commits, 50+ Deliverables

The Compliance Framework: Three Standards, One Program

Most GRC programs organize around a single framework. ResolvX operates across three simultaneously, which reflects the real compliance environment of a cloud-native fintech operating in EU markets.

Phase 1: Risk Management - Starting Where Every GRC Program Should

Before a single control was mapped, the threat landscape had to be understood in ResolvX's specific context. A fintech handling AI-powered dispute resolution faces threats that a generic risk register template will not surface.

I built a dedicated Threat Landscape document covering the fintech-specific risk environment before scoring a single entry in the register. This included: financial data as a premium target for both financially motivated and state-sponsored actors; AI model manipulation as an emerging attack surface for companies whose core product makes automated financial decisions; and GDPR breach notification risk, where a 72-hour statutory clock starts from the moment of awareness - creating a direct financial and reputational exposure for every incident.

The risk register included a critical entry that most standard GRC templates do not contain: AI model decision auditability, flagged at Score 15/High. In a company where AI makes financial dispute decisions on behalf of regulated enterprise clients, the inability to produce an audit trail of individual model outputs is a compliance risk under GDPR Article 22 and an emerging requirement under the EU AI Act's high-risk AI provisions.

Including that entry from Day 1 meant the compliance program was designed for the regulatory environment ResolvX will actually face and not the one it faced in 2019.

Phase 4: Vendor Risk - Assessing Every Tier 1 Vendor, Building the GDPR Register

ResolvX operates with 6 Tier 1 critical vendors, those with direct access to production systems or client financial data. All 6 were assessed against a 25-question questionnaire across 5 domains. All 6 hold relevant certifications. All 6 have active Data Processing Agreements in compliance with GDPR Article 28.

The sub-processor register - a GDPR Article 28 and Article 30 requirement - documents how ResolvX manages both its own employee data and the client financial data it processes as a data processor on behalf of enterprise clients. This distinction matters: ResolvX is a data controller for employee data and a data processor for client financial data. The compliance obligations differ for each role.

Phase 5: Incident Response - 3 Runbooks, 1 Tabletop, 1 Critical Finding

The incident response program was built to operate, not to exist. That distinction matters. An IR plan that has never been tested is a policy document. An IR plan that has been tested is an operational capability.

Three runbooks were written for the most probable incident scenarios in ResolvX's environment: phishing (the most common initial access vector), ransomware (the highest-impact operational threat), and data breach (the highest-impact regulatory threat, given GDPR exposure).

The February 2026 tabletop simulation used a scenario designed around ResolvX's actual toolstack: an Okta anomaly detection alert flagging impossible travel - a credential compromise scenario that could lead to unauthorized access to client financial records.

The critical finding: containment decision authority was undefined. Two stakeholders deferred to each other for over 11 minutes before action was taken. In a real P1 incident, those 11 minutes represent uncontrolled attacker dwell time in a system containing financial records and PII.

The corrective action: a named decision authority for each response phase was added to the IR plan. The plan was revised and re-communicated. The post-revision P1 containment SLA is 15 minutes.

Phase 6: Audit Readiness - 0 Major Nonconformities

The Q1 2026 internal audit returned 0 major nonconformities and 2 minor observations. This is not a trivial result. In a first-cycle internal audit, major nonconformities are common. They indicate that documented controls do not have corresponding evidence of operation. Zero major NCs means the evidence discipline was maintained throughout the program build.

The 2 minor observations; a contractor training gap and an overdue access review cycle. These are exactly the kind of findings that internal audits are designed to surface. They are low-severity, owned, remediated, and logged. They will not appear as findings in the external audit.

Phase 8: The Trust Center - The Deliverable That Changed the Frame

Every GRC program produces internal documentation. The ResolvX program produced something additional: a live, public-facing Trust Center accessible to anyone at any time.

The Trust Center is not a summary. It is a commitment, a public statement of security posture, compliance status, vendor controls, data handling practices, and incident response SLAs, backed by the evidence library that the preceding seven phases produced. Every metric on the page is traceable to a specific document, a specific control test, a specific audit finding.

Building it reframed how I think about GRC deliverables entirely. Internal documentation answers the question: "Did we do the work?" The Trust Center answers a different question: "Would a sophisticated enterprise client trust us with their financial data?"