GRC Framework for a Small Risk Team: One Control Library, Five Workflows, No Enterprise Platform

TL;DR

• A GRC program that runs on one control library and five traceable workflows beats a half-implemented enterprise platform every time.
• The control library is the foundation: one ID, one owner, one test, mapped to every framework that requires it.
• Five workflows cover the core: risk assessment, control testing, issues management, vendor oversight, and compliance monitoring. Each needs a cadence, output, and owner.
• Enterprise platforms accelerate a program that already works. Build the program first.

The first compliance hire at a Series B fintech asked a reasonable question at the 90-day mark: “What tool should we buy for GRC?”

The answer was: none yet. What they needed first was a control list, a testing schedule, and a place to track open gaps. Once those three things existed and were being used consistently, the platform question would have a real answer. Without them, a platform purchase was just organizing the absence of a program.

That’s the GRC framework problem for small teams. The instinct is to find the right software. The actual need is to define the workflows the software would eventually run. This post is about the workflows.

Start with one control library

A control library is the backbone of a GRC program. Not a policy. Not a risk register. Not a compliance calendar. The control library, because it’s the single source of truth that every other workflow references.

What the control library contains:

The framework mapping column is where most small teams underinvest. When your control library maps each control to the specific framework requirements it satisfies, a new audit or certification doesn’t require a ground-up gap analysis—it requires a filter on the library. 80–96% of core security controls overlap across SOC 2, ISO 27001, PCI DSS, and NIST CSF. If MFA enforcement is in your library and is tested, that single entry evidences compliance with four different framework requirements simultaneously.

Practical setup: Start with the minimum control set for your current obligation stack. If you’re subject to GLBA, SOC 2, and state money transmission requirements, build 80–120 controls that cover those obligations and no more. Add controls when you take on new frameworks, not in anticipation of them.

The five workflows

A GRC program is a set of recurring processes that produce specific outputs. Five workflows cover the core for a team of 1–4 people.

Workflow 1: Risk assessment

What it produces: A risk register showing identified risks, inherent scores, control assignments, residual scores, and treatment decisions.

Cadence: Full update annually. Triggered update on significant business changes (new product, new vendor relationship, new regulatory requirement, major incident).

Owner: Risk and compliance lead.

The minimal version: Start with the Risk Register — Fintech Edition (free) if you don’t have one—141 pre-populated risks across 21 categories, with suggested inherent scores and control descriptions. Populate residual scores based on your actual control library. Update annually with a structured business-line review session.

Connection to other workflows: Risk scores drive the control testing cadence—high-residual risks need more frequent testing. Gaps identified in the risk assessment feed the issues log. Vendor risk scores come from this workflow and feed vendor oversight.

Workflow 2: Control testing

What it produces: A test log with test ID, control ID, test date, tester, procedure, sample, evidence, exception, and result (Effective / Ineffective / Design gap).

Cadence: Tied to control test frequency from the library. Annually for most controls; quarterly for highest-risk controls; monthly for critical automated controls where anomalies could go undetected.

Owner: Second-line risk/compliance function or internal audit (if present). For small teams, the compliance lead runs testing on first-line controls.

The minimal version: A single test log tab in a workbook, with one row per test. Attach or reference evidence (screenshots, reports, exports) by a document ID stored in a shared folder. The test log is the artifact an auditor pulls—it should be readable without explanation.

Connection to other workflows: Test failures feed the issues log. Aggregate test results feed the compliance monitoring report. Significant gaps inform the risk assessment update.

For a structured approach to building the test universe that feeds this workflow, the compliance monitoring plan and test universe guide covers how to decide what gets tested, how often, and in what sequence.

Workflow 3: Issues management

What it produces: An issues log tracking every gap, finding, and MRA from identification through remediation to validated closure.

Cadence: Continuous input; weekly status review; monthly executive report.

Owner: Risk/compliance lead. Business line owners for remediation.

The minimal version: One row per issue, with: source (audit finding, exam MRA, self-identified, test failure), severity (Critical / High / Medium / Low), root cause, owner, due date, remediation steps, evidence of closure, and status. Never delete closed issues—archive them with closure evidence attached.

Connection to other workflows: Issues drive follow-up testing in the control testing workflow. Recurring root causes feed the risk assessment. Bank partner and examiner requests for your issues process point here.

A common failure: tracking issues in the same workbook as test results or policies, with no clear separation. The issues log has a lifecycle—open to remediation to validated closure—that requires its own structure, independent of where the finding came from.

Workflow 4: Vendor oversight

What it produces: A vendor inventory with risk tier, due diligence file, and ongoing monitoring cadence for each vendor.

Cadence: Initial due diligence before onboarding. Annual review for Tier 1 vendors; 18-month cycle for Tier 2; biennial or event-triggered for Tier 3.

Owner: Risk/compliance lead or a named vendor management function.

The minimal version: A vendor register with tiering fields (criticality, access to customer data, access to financial systems, regulatory significance), a due diligence checklist (SOC 2 / audit report review, insurance verification, BCP/DR verification, SLA review), and a monitoring calendar.

Connection to other workflows: Vendor risks feed the risk register. Vendor due diligence outputs feed the control library (third-party controls). Vendor incidents feed the issues log. Bank partner reviews often start with a request for the vendor register.

Workflow 5: Compliance monitoring

What it produces: A compliance calendar showing regulatory obligations, monitoring tests scheduled and completed, results, exceptions, and the linkage back to the obligation.

Cadence: Monthly reporting; quarterly reviews; annual program assessment.

Owner: Compliance lead.

The minimal version: A monitoring calendar with: obligation (Reg E error resolution, GLBA privacy notice, BSA/AML SAR filing timeliness), product/process in scope, monitoring procedure, frequency, owner, last result, next scheduled date. The calendar should be traceable—each monitoring test should link back to completed workpapers and any exceptions logged in the issues workflow.

Connection to other workflows: Monitoring test failures feed issues. Obligation inventory informs the risk assessment. The calendar is what examiners pull when they assess your Compliance Management System.

Tying the five workflows together

The workflows are independent only in execution. In function, they form a closed loop:

Risk Assessment → identifies risks and control gaps
    ↓
Control Testing → validates controls are working
    ↓
Issues Management → tracks failures and remediation
    ↓
Risk Assessment Update → reflects remediated gaps

Vendor oversight and compliance monitoring run parallel to this loop—vendor oversight applies the risk/control logic to third parties; compliance monitoring verifies obligation-specific performance.

The control library is the axis. Every workflow references control IDs. A test failure references a control ID. An issue references a control ID. A risk entry references control IDs. When a bank partner or examiner asks “show me your control for X,” you pull the control ID, find the last test date and result, see if there’s an open issue, and produce the evidence in one lookup instead of assembling it from four different spreadsheets.

What “no enterprise platform” actually means

Not no tools—no enterprise GRC platform. Microsoft Excel or Google Sheets can hold a control library, test log, issues register, and vendor inventory for any team managing fewer than 200 controls. A shared document system (SharePoint, Google Drive, Notion) handles policies and evidence storage. A project management tool (Asana, Linear, Jira) can track issue remediation tasks if your issues log doesn’t have enough workflow functionality.

The limitation of this setup is version control and audit trails—spreadsheets don’t automatically track who changed what. Compensate by: maintaining a change log tab in key workbooks; requiring formal version numbers and approval dates on policies; storing completed test workpapers in a date-stamped folder structure with no overwrites. These practices replicate what a platform would automate.

The RCSA (Risk & Control Self-Assessment) post covers how to structure the control testing and self-assessment workflow in a way that holds up under OCC and FDIC examination—which informs how your control testing workflow should be documented.

Platform decision triggers

Buy a platform when one or more of these becomes true:

• Evidence collection for a single audit consumes more than 2 weeks of compliance staff time
• Two concurrent audits (SOC 2 + bank partner due diligence, for example) create version control or evidence attribution problems
• Control owners are re-answering the same questionnaire in four different formats for four different audiences in the same quarter
• The team is spending more time maintaining the spreadsheet structure than using it
• A new regulatory requirement (NYDFS Part 500 annual certification, Colorado AI Act) requires automated monitoring that spreadsheets can’t produce

The platform doesn’t create the program. It scales the program. The GRC Starter Kit is the content layer—control library starter, risk register, issues tracker, policy templates, and KRI library—that you populate regardless of what tool you use to hold it.

So what?

The question “what tool should we buy” has one good answer: whatever tool runs the program you’ve built. The question before that is: have you built it?

One control library, five traceable workflows, and consistent documentation practices is a defensible GRC program. It is what bank partners and examiners actually audit. It is what prevents a “we’ll handle that when we get a platform” conversation from becoming an MRA when the examiner walks in.

Start with the workflows. Platform second.