This is where most GRC programs stall. They build the right capabilities, earn the certifications, develop the policies—and then bury it all behind manual processes that frustrate customers and drain internal resources.

The fix isn’t hiring more people to answer security questionnaires faster. It’s rethinking how trust gets delivered.

The Bottleneck Problem

Picture the typical enterprise sales cycle. A prospect is interested. They’ve seen the demo, liked the product, and have budget. Then procurement sends over a 300-question security questionnaire. Or they ask for your SOC 2 report. Or they want to schedule a call with your security team.

What happens next determines whether compliance is a gate or an enabler.

In the gate model, the request lands in someone’s inbox. Maybe it’s a GRC analyst, maybe it’s a sales engineer, maybe it’s whoever answered the last one. They dig through folders to find the latest documents. They copy-paste answers from previous questionnaires, hoping the information is still accurate. They wait for approvals. Days pass. The prospect’s enthusiasm cools. Competitors who respond faster gain an edge.

This model doesn’t scale. Every new customer means more manual work. Every certification you add means more documents to manage and more questions to answer. Growth becomes a burden on the compliance team instead of a victory.

The Infrastructure Model

The alternative is treating trust delivery as infrastructure—systems that serve customers automatically, consistently, and instantly.

This isn’t about replacing humans with bots. It’s about removing humans from tasks that don’t require human judgment, so they can focus on work that does.

Self-service trust centers. Instead of emailing documents on request, publish them where customers can access them directly. SOC 2 reports, penetration test summaries, compliance certifications, security whitepapers—all available behind a simple NDA click-through. Prospects get what they need instantly. Your team doesn’t lift a finger.

Automated evidence collection. The bane of audit prep is chasing screenshots and exports from a dozen different systems. Automate that. Pull user access reviews from your identity provider. Pull vulnerability scan results from your security tools. Pull change management records from your ticketing system. When audit season arrives, the evidence is already there.

Real-time compliance posture. Point-in-time audits are table stakes. The next level is continuous monitoring—dashboards that show your current compliance state, flag drift before it becomes a finding, and give customers confidence that you’re not just compliant once a year but compliant right now.

Intelligent questionnaire response. Security questionnaires are repetitive by design. Most questions map to the same underlying controls. Build a knowledge base of your canonical answers, tagged by control and framework. Use it to auto-populate responses, then have humans review and customize. What took days now takes hours.

The GRC Engineering Mindset

This shift requires a different way of thinking about compliance work. Traditional GRC is document-centric: policies, procedures, evidence binders, audit reports. Automated GRC is system-centric: integrations, workflows, data pipelines, APIs.

That doesn’t mean everyone on the GRC team needs to become a software engineer. But it does mean thinking like one:

Build once, use many times. Every time you manually generate a report or answer a question, ask whether that task could be automated. If you’ll do it more than twice, it’s worth systematizing.

Treat compliance data as a product. Your evidence, your control status, your certification records—these have consumers, both internal and external. Design how that data flows with the same care you’d design a customer-facing feature.

Version control your artifacts. Policies change. Controls evolve. Evidence gets updated. If you can’t trace what was true at a specific point in time, you’ll struggle in audits and incident response. Treat your compliance artifacts like code: versioned, reviewable, auditable.

Measure cycle time. How long does it take to respond to a security questionnaire? To produce evidence for an auditor? To onboard a new vendor? These are your compliance SLAs. Track them, set targets, and improve systematically.

The Business Case

Automation isn’t just about efficiency—though the efficiency gains are real. A GRC team that automates well can support 10x the customer base without 10x the headcount. That’s leverage.

But the bigger win is speed. In competitive deals, the vendor who delivers trust artifacts fastest often wins. When a prospect can self-serve your SOC 2 report at 10pm on a Sunday, you’re not waiting until Monday for someone to find it and email it over. When questionnaire responses come back in hours instead of weeks, you’re demonstrating operational maturity that reinforces the trust you’re trying to establish.

Speed also compounds internally. When evidence collection is automated, audit prep shrinks from a multi-week scramble to a routine process. When compliance posture is visible in real-time, you catch issues early instead of discovering them during the audit. When policies and controls are systematized, onboarding new team members takes days instead of months.

Getting Started

You don’t need to automate everything at once. Start with the highest-friction, highest-volume pain points:

If security questionnaires are killing you: Build a response library. Map your most common questions to canonical answers. Even a well-organized spreadsheet is a 10x improvement over starting from scratch each time.

If document requests are constant: Stand up a basic trust center. It can be as simple as a password-protected page with your key documents. Upgrade to a proper portal when volume justifies it.

If audit prep is a fire drill: Identify your most painful evidence items and automate those first. User access reviews and vulnerability scans are often quick wins because the data already exists in systems with APIs.

If you’re not sure where to start: Instrument what you have. Track how long things take. Follow the pain. The data will tell you where automation has the highest ROI.

Trust at Scale

The companies that win on trust in the next decade won’t be the ones with the most certifications on their website. They’ll be the ones who deliver trust effortlessly—to customers, to auditors, to partners, to regulators.

That requires treating compliance not as a periodic checkbox exercise, but as operational infrastructure. It requires building systems that scale. It requires the GRC Engineering mindset.

In Part 1, we talked about listening to customers to know what trust capabilities to build. In Part 2, we’ve covered how to deliver those capabilities at scale. Together, they form a model for GRC that isn’t just a cost center or a necessary evil—but a genuine competitive advantage.

The technology exists. The patterns are proven. The question is whether your compliance program is ready to make the shift.

This is Part 2 of a two-part series on building trust as a business enabler. Read Part 1: “Customer Trust as a Compass” for how to use sales partnership to shape your compliance roadmap.

They start with a framework—SOC 2, ISO 27001, GDPR—and work inward. The logic seems sound: pick a standard, map the controls, close the gaps, get certified. Rinse and repeat for the next framework on the list.

But here’s the problem: that approach treats compliance as an internal exercise. It optimizes for auditors, not customers. And in a world where trust is a competitive differentiator, that’s a costly mistake.

The companies winning on trust aren’t just checking boxes. They’re listening to what their customers actually need—and building compliance programs that deliver it.

The Intelligence Gap

Your sales and customer success teams talk to prospects and customers every day. They hear the objections, field the security questionnaires, and sit through the procurement reviews. They know exactly where deals stall, which competitors are winning on trust, and what certifications actually move the needle in your market.

That’s gold. And most GRC teams never see it.

Instead, compliance priorities get set in a vacuum. Leadership picks the next certification based on industry trends, analyst reports, or whatever the last lost deal mentioned in passing. The GRC team disappears for six months to implement it. Sales keeps struggling with the same objections. Everyone wonders why the new certification didn’t magically fix pipeline velocity.

The disconnect isn’t malicious—it’s structural. GRC teams are buried in control implementation and audit prep. Sales teams are focused on quota. Nobody’s job is to connect the dots.

Until you make it someone’s job.

Building the Feedback Loop

The fix isn’t complicated, but it requires intentionality. You need a consistent mechanism for customer trust intelligence to flow into your compliance planning process.

Start with the friction points. Work with sales leadership to identify where trust-related objections are killing or stalling deals. Not anecdotes—data. Which questions come up repeatedly in security reviews? Which certifications do prospects ask about that you don’t have? Where are you losing to competitors on compliance posture?

Categorize the asks. Not every customer request deserves a six-month implementation project. Some needs can be addressed with better documentation or a clearer explanation of existing controls. Others require net-new capabilities. Understanding the difference prevents overengineering and helps you move faster on quick wins.

Prioritize by business impact. This is where GRC earns its seat at the table. Frame compliance investments in terms of revenue enabled, deals unblocked, or market segments unlocked. A certification that opens up enterprise or regulated industry sales is a different conversation than one that checks a theoretical box.

Close the loop. When you ship a compliance capability that came from customer feedback, tell the sales team. Let them know what’s now available, how to position it, and where to find the evidence. This builds trust in the partnership and encourages more intelligence sharing.

From Cost Center to Growth Engine

The traditional view of compliance is defensive: avoid fines, pass audits, don’t get breached. That framing makes GRC a cost center—necessary but not strategic.

Customer-driven compliance flips the script.

When your roadmap is shaped by real customer needs, every compliance investment has a clear line to revenue. You’re not just reducing risk; you’re removing friction from the sales process. You’re not just satisfying auditors; you’re satisfying buyers.

This changes how the business sees the GRC function. Instead of the team that says “no” or slows things down, you become the team that helps close deals. Instead of a budget line item to minimize, you become an investment with measurable returns.

That shift doesn’t happen overnight, and it doesn’t happen by accident. It requires GRC leaders to step out of the audit prep mindset and engage with the commercial side of the business.

The Partnership Model in Practice

What does this look like day-to-day?

It means GRC has a regular sync with sales leadership—not to review security questionnaire responses, but to discuss pipeline trends and trust-related blockers. It means someone from the compliance team occasionally joins customer calls during procurement reviews, not to answer questions on the spot but to hear what customers actually care about.

It means treating RFPs and security questionnaires as market research, not just administrative burden. Every question a prospect asks is a data point about what the market values. Aggregate enough of those data points and patterns emerge.

It means sharing your compliance roadmap with sales before it’s finalized, and actually incorporating their feedback. They might not understand the technical details of control implementation, but they understand which capabilities would help them sell.

And it means measuring success differently. Audit outcomes still matter, but so do metrics like: time to complete security reviews, win rate on deals with compliance requirements, and customer satisfaction with your trust posture.

Trust Is the Product

Here’s the mindset shift that ties it all together: in B2B SaaS, trust isn’t a byproduct of your product—it is your product.

Customers aren’t just buying your features. They’re buying confidence that their data is safe, that you’ll meet your commitments, and that doing business with you won’t create liability for them. The companies that understand this don’t bolt compliance on as an afterthought. They build it into how they operate, how they sell, and how they prioritize.

Your sales team is on the front lines of that trust exchange. They know what customers need to feel confident. The question is whether your compliance program is listening.

This is Part 1 of a two-part series on building trust as a business enabler. In Part 2, we’ll explore how to operationalize customer trust at scale—automating evidence delivery, building self-service trust infrastructure, and turning compliance from a gate into a growth engine.

You’ve heard about a new GRC platform. The features sound promising. The screenshots look compelling. But then comes the inevitable friction:

“Schedule a demo with our sales team.”

“Sign up for a 14-day trial and spend 3 hours configuring it.”

“Create 50 test records before you can see how the dashboards actually work.”

For busy security and compliance professionals, this is a non-starter. You don’t have hours to invest before you can evaluate whether a tool fits your workflow. You need to see the platform in action—with real-looking data, real relationships between records, and real dashboards that tell a story.

That’s exactly why we built one-click demo data into GigaChad GRC.

Introducing Demo Data: A Complete GRC Environment in Seconds

When you fork or clone GigaChad GRC, you’re not starting with a blank slate and wondering “now what?” With a single click, you can populate your instance with a comprehensive, realistic GRC environment:

50+ Security Controls mapped to frameworks, with varied implementation statuses so you can see what “in progress” vs. “implemented” actually looks like in the interface.

Full Framework Hierarchies including SOC 2 Type II and ISO 27001:2022 with their complete requirement structures—not just names, but descriptions, guidance, and proper parent-child relationships.

20 Realistic Vendors spanning categories from cloud infrastructure (AWS) to HR systems (ADP) to communication tools (Slack), each with appropriate risk tiers and completed security assessments.

25 Documented Risks across technical, operational, and compliance categories, complete with impact and likelihood ratings that make the risk heatmap actually useful to evaluate.

100+ Evidence Items linked to controls, showing how document management and evidence collection works in practice.

50 Employees with training records, background check statuses, and compliance metrics—because GRC isn’t just about technology.

This isn’t lorem ipsum data. It’s a thoughtfully constructed environment that mirrors what a real organization’s GRC program looks like.

Three Ways to Access Demo Data

We believe in meeting users where they are. That’s why demo data is accessible through multiple methods:

1. The Onboarding Banner

First-time users with an empty organization see a friendly welcome banner with a prominent “Try with Demo Data” button. One click. That’s it. The platform populates while you wait, and you’re exploring real workflows within a minute.

2. Settings Page

Prefer to poke around first? No problem. Navigate to Settings → Organization → Demo Data whenever you’re ready. The interface shows exactly what will be created before you commit, and a progress indicator keeps you informed during the load.

3. API Endpoint

For developers, CI/CD pipelines, or automated testing environments:

The API returns a detailed breakdown of every record created, making it easy to verify your environment is ready for whatever you’re building.

Zero Configuration Required

Here’s the complete process to go from “I’ve never seen this repo” to “I’m clicking through a fully-populated GRC platform”:

That’s three commands. Docker handles the infrastructure. The start script waits for services to be healthy. Your browser opens automatically. Click “Dev Login” (no password needed in demo mode), hit “Load Demo Data”, and you’re exploring.

No environment variables to configure. No database migrations to run manually. No seed scripts to hunt down. No YAML files to edit.

The entire experience is designed around one principle: reduce time-to-value to near zero.

Real Scenarios, Not Placeholder Text

What makes demo data truly useful is that it enables you to evaluate real workflows:

Scenario: Control Implementation Tracking

Navigate to the Controls module. You’ll see controls in various states—some fully implemented with linked evidence, others marked as “in progress” with partial documentation, and a few that haven’t been started. Filter by status. Assign an owner. Link evidence. This is exactly what your team would do day-to-day.

Scenario: Vendor Risk Assessment

Open the TPRM module. Browse vendors by risk tier. Click into a vendor to see their completed assessment, contract details, and associated risks. Add a note. Trigger a reassessment. The workflow feels familiar because it mirrors real vendor management.

Scenario: Compliance Gap Analysis

Check the Framework module. See SOC 2 requirements alongside their mapped controls. Identify which requirements have full coverage, which have partial coverage, and which have gaps. Export a gap report. This is audit prep in action.

Scenario: Risk Heatmap Evaluation

Visit the Risk Dashboard. The heatmap is populated with risks distributed across likelihood and impact dimensions. Click a cell to drill into specific risks. Evaluate treatment options. See how the overall risk posture changes as you mark risks as mitigated.

These aren’t contrived examples—they’re the actual daily workflows of GRC professionals, and demo data lets you experience them immediately.

When You’re Ready: Clean Reset

Demo data is explicitly marked throughout the interface with a purple “Demo Mode Active” banner. There’s no confusion about what’s real and what’s sample data.

When you’re ready to move to production:

1. Navigate to Settings → Organization → Demo Data

2. Click “Reset All Data”

3. Type the confirmation phrase

4. Your organization is now a clean slate, ready for your real compliance program

User accounts, organization settings, and system configuration are preserved. Only the sample records are removed.

Built for Evaluators, Developers, and Contributors

For Evaluators: Stop wasting time on sales calls and configuration. Clone the repo, run the script, click the button. In under five minutes, you’ll know whether GigaChad GRC fits your needs.

For Developers: Demo data provides a consistent, reproducible environment for development and testing. The API endpoint integrates seamlessly with CI pipelines and automated test suites.

For Contributors: When you fork the repo to contribute a feature or fix a bug, demo data means you don’t need to understand the full domain model just to see your changes in context. Load the data, make your changes, see them work with realistic records.

Try It Today

GigaChad GRC is open source and ready to run on your machine right now:

Within minutes, you’ll be exploring a fully-featured GRC platform with realistic demo data—no sales call, no credit card, no configuration headaches.

Because evaluating software should be as easy as using it.

The buzzwords are everywhere: AI-driven insights, intelligent automation, machine learning risk scoring. What’s missing is an honest answer to the question that matters: where does AI reduce pain versus create new problems?

After building AI into GigaChad GRC and watching practitioners use it, I’ve developed a framework I haven’t seen elsewhere. This post covers both philosophy and implementation.

Part 1: The Philosophy

The AI Hype Problem

Compliance has constraints most AI implementations ignore: auditability, explainability, accountability.

When an auditor asks “why did you rate this risk as high?”, the answer cannot be “the AI said so.” Regulators need evidence, not confidence scores from black boxes. Your board needs to understand methodology, not just trust an algorithm.

Most vendor AI optimizes for demos, not these realities.

AI that doesn’t help:

• “AI-generated policies” with no traceability to requirements

• Risk scores from black boxes auditors can’t explain

• Chatbots hallucinating compliance requirements

• Auto-classification with no override mechanism

The question isn’t “can AI do this?” It’s “should it, and how do we maintain control?”

Where AI Actually Helps

Patterns emerged from real usage. AI adds value in five categories—all sharing one property: AI handles toil while humans retain judgment.

1. Evidence Collection Automation

The sweet spot. Pull AWS configs, GitHub branch protection, Okta MFA status—mechanical tasks that previously required expensive integrations or manual screenshots. AI coordinates collection, not interpretation. Humans still decide if configurations meet requirements.

2. Questionnaire Response Drafting

Match incoming questions to your knowledge base, draft from previous answers. Critical: human always approves before sending. AI accelerates; it doesn’t decide. Prior responses are vetted, drafts are editable, the audit trail shows human approval.

3. Risk Categorization and Tagging

AI suggests categories, related controls, similar risks—with confidence scores. Low-confidence gets scrutiny; high-confidence can be batch-approved. Human confirms or overrides.

4. Report Generation

Synthesize control status into executive summaries, format evidence for auditors, summarize findings by severity. Synthesis, not judgment—underlying data remains the source of truth.

5. Smart Search

Natural language queries: “Show me encryption controls that failed testing last quarter.” AI translates intent into structured queries. Finding, not deciding.

Where AI Doesn’t Belong (Yet)

Autonomous control testing. “AI says we’re compliant” isn’t auditable. AI surfaces evidence; humans make pass/fail determinations.

Unsupervised policy creation. Policies encode organizational context. AI drafts; humans must review before publishing.

Risk acceptance decisions. Business judgment with accountability. AI quantifies; humans with authority decide.

Audit responses without review. One hallucination torpedoes an audit. Every character must be human-reviewed.

The Principle

AI should reduce toil, not replace judgment.

If an auditor asks “why did you do this?” and your answer is “the AI said so”—you’ve built a liability, not a tool.

Part 2: The Implementation

GigaChad GRC implements AI through Model Context Protocol (MCP) servers—keeping AI modular, optional, and auditable.

Why MCP?

MCP provides a standard way for AI tools to interact with external systems. Instead of embedding inference in your app, you expose tools that AI clients call.

This separation matters:

• AI reasoning stays in the LLM. Models, prompts, conversation management—the client’s problem.

• Domain logic stays in code. GRC knowledge, integrations, business rules in TypeScript, not prompts.

• Works with multiple clients. Claude, Cursor, custom agents—any MCP client works.

• Optional by design. Platform works without AI. Capabilities are additive.

The Architecture

Three MCP servers, each with a distinct purpose:

grc-evidence: Automated Evidence Collection

This server handles the mechanical work of gathering compliance evidence from external systems. No AI inference required—just structured API calls to cloud providers and security tools.

Tools exposed:

Here's how a tool is defined:

When called, the tool handler collects structured evidence:

The output is structured JSON that gets uploaded to the evidence library. No interpretation—just facts about configuration state.

grc-compliance: Testing and Reporting

This server automates control testing and report generation. It runs predefined test procedures against collected evidence.

Tools exposed:

The control tester works with evidence to produce auditable results:

Test results include the evidence examined, criteria applied, and outcome—all auditable.

grc-ai-assistant: Intelligent Analysis

This server uses LLM inference for analysis tasks. Unlike the other servers, it calls AI models to generate insights.

Tools exposed:

The risk analyzer shows how AI suggestions are structured:

Every AI suggestion includes:

• Scores with scales so humans understand the range

• Rationale explaining why the AI reached this conclusion

• Related items for context

• Compliance impact tied to specific frameworks and controls

The rationale field is critical. It’s what you show the auditor when they ask “why?”

Building an MCP Server: The Pattern

If you want to add your own AI capabilities, here’s the pattern:

1. Project structure:

2. Server setup:

3. Connect to GigaChad GRC APIs:

Your tools can call the platform APIs to read and write data:

The Audit Trail Problem

Here’s the challenge: every AI-initiated action must be auditable.

When an AI tool collects evidence, we need to know:

• What tool was called

• What parameters were passed

• What was returned

• When it happened

• Which AI session initiated it

The solution: audit logging middleware that wraps every tool call.

Evidence uploaded by AI is tagged with the collection method:

Auditors can filter to see all AI-collected evidence. Nothing is hidden.

Part 3: Practical Patterns

Three patterns emerged from production usage:

The “AI Suggests, Human Confirms” Pattern

Every AI output is a suggestion, not a decision.

Low-confidence suggestions (< 0.7) are flagged for detailed review. High-confidence suggestions (> 0.9) can be batch-approved. The threshold is configurable per organization.

The human sees:

• What the AI suggests

• How confident it is

• Why it reached that conclusion

• What alternatives exist

The human decides whether to accept, modify, or reject.

The “Evidence First, Analysis Second” Pattern

Never let AI analyze something you haven’t collected in structured form.

Wrong: “AI, tell me if we’re SOC 2 compliant.” Right: “Collect AWS configs, then show me the analysis.”

The evidence is the source of truth. AI explains evidence; it doesn’t replace it. Auditors can always drill down from the AI summary to the raw data.

The “Escape Hatch” Pattern

Every AI feature has a manual fallback.

• AI evidence collection failing? Collect manually.

• AI risk scoring seems wrong? Override it.

• AI report generation broken? Export the data and build your own.

AI failures don’t block core workflows. The platform is fully functional without any AI server running.

Users can disable AI suggestions per module in settings. Some organizations disable AI entirely for regulated data. The platform respects that.

Closing: AI as Augmentation, Not Replacement

The best AI in GRC is invisible. It removes the tedious work—evidence collection, questionnaire drafting, report formatting—without inserting itself into decisions that require human judgment.

Here’s the test: can you explain every AI-influenced decision to an auditor using evidence they can verify? If yes, you’ve built AI that helps. If no, you’ve built a liability.

The MCP architecture keeps AI capabilities modular and optional. You can use all three servers, just one, or none. You can add your own. You can disable features that don’t fit your risk appetite.

Build for the auditor’s question: “Show me why you made this decision.”

If the answer involves evidence, human review, and documented rationale, you’re doing it right. If the answer is “the AI said so,” go back to the drawing board.

Get Involved

The MCP servers are in the repo:

• mcp-servers/grc-evidence

• mcp-servers/grc-compliance

• mcp-servers/grc-ai-assistant

If you build new evidence collectors—for tools we haven’t covered yet—pull requests are welcome. If you’ve found ways to make AI more auditable in GRC, the community wants to hear about it.

The vendors will keep adding “AI-powered” to their marketing. We’ll keep building AI that actually helps practitioners.

The author still believes AI should reduce toil, not replace judgment. Still maintains the MCP servers. Still drinks too much coffee.

“Great stuff! I like how you explain the tradeoffs of shared libraries vs shared services and shared database vs database per service. Also, as a ‘biased towards buy’ person, it shows the tradeoffs that a team has to think about when weighing in on a commercial platform vs DIY: do you really have the headcounts to worry about traceability in each header, transaction IDs, network hops, etc.”

He’s right. My previous posts focused on the upside—escaping vendor lock-in, building exactly what you need, the satisfaction of owning your stack. This post addresses the other side of the ledger.

I built GigaChad GRC. Here’s what it actually cost.

The Costs I Expected

Let’s get the obvious ones out of the way. Anyone considering DIY knows about these:

Initial development time. Nights, weekends, the caffeine-fueled push to get something working. I knew this going in.

Learning curve. NestJS, Prisma, Keycloak, Traefik, Docker Compose, Terraform—each one has a learning curve. I budgeted for this.

Infrastructure setup. PostgreSQL, Redis, object storage, authentication. Table stakes for any platform.

These are the costs everyone calculates. They’re also the smallest part of the real total.

The Costs I Didn’t Expect

The Distributed Systems Tax

That LinkedIn comment nailed it: correlation IDs, traceability, network hops.

GigaChad GRC has seven microservices. Each one is a debugging boundary. When a request fails, which service caused it? The logs don’t correlate themselves.

I didn’t add correlation IDs from day one. That decision cost me a two-hour debugging session that should have been ten minutes. The request touched Controls, then Frameworks, then back to Controls. The failure happened in the second hop. Without correlation IDs propagating through headers, I was grep-ing timestamps across three log streams trying to reconstruct the sequence.

The lesson: Every microservice boundary is a debugging boundary. The architecture diagrams don’t show the operational complexity hiding in each arrow.

Features that look simple on paper touch multiple services:

• “Add evidence to a control” → Controls service + storage abstraction + audit logging

• “Test a control against a framework” → Controls + Frameworks + Evidence

• “Generate an audit report” → Audit service + Controls + Frameworks + Evidence + Reports

That “simple” feature isn’t one change—it’s coordinated changes across services, with testing, deployment, and the prayer that nothing breaks in production.

The Upgrade Treadmill

Dependencies don’t maintain themselves.

When Keycloak releases a security patch, that’s my weekend. When PostgreSQL announces a major version with breaking changes, that’s my migration to plan. When npm audit shows 47 vulnerabilities of varying severity, that’s my judgment call on which ones matter.

Commercial vendors absorb this. They have teams dedicated to keeping infrastructure current. They test upgrades before you see them. They eat the cost of compatibility work.

DIY means you ARE the vendor. Every upstream change is your responsibility.

In the past year, I’ve dealt with:

• Prisma ORM updates that changed query behavior

• Breaking changes in the MCP SDK that required refactoring all three servers

• Node.js version updates that broke Docker builds

• Keycloak realm export format changes that invalidated my configuration

None of these were on my roadmap. All of them consumed time I’d planned for features.

The “It Works on My Machine” Problem

Development happens on my M1 Mac. Production runs on Linux. Docker papers over most differences—until it doesn’t.

Memory limits that seemed fine locally caused OOM kills in production. Network policies that don’t exist in docker-compose become walls in Kubernetes. File system permissions that work on macOS fail silently on Linux.

The first real production deployment surfaced a dozen assumptions I didn’t know I’d made.

Commercial platforms have dedicated infrastructure teams. They’ve already hit these issues. They’ve documented the solutions. You get the benefit of their experience without paying for their mistakes.

Documentation Debt

Nobody wants to write docs. I certainly didn’t.

But without docs:

• Every new team member’s onboarding is a conversation (my time)

• “How do I add a new integration?” gets asked repeatedly (my time)

• API changes without changelogs become support burden (my time)

• Six months later, I don’t remember why I made that decision (my time, debugging my own code)

Vendor platforms have technical writers. They have documentation teams. They have customer success people who update the help center.

You are the documentation team. You are the technical writer. You are customer success. Every role you don’t fill is a gap the platform’s users will feel.

The Support Burden

Commercial vendors have support tiers, SLAs, escalation paths. When something breaks, you open a ticket.

DIY means:

• No vendor to call

• No SLA for a fix

• No one to blame but yourself

• Your weekend is the incident response team

When the platform breaks at 11 PM, you’re not waiting for a vendor response. You’re debugging. When it breaks during a demo, you’re not pointing at someone else’s bug. You’re apologizing and fixing.

The psychological weight of sole ownership is harder to quantify but real. Commercial platforms let you externalize blame. DIY makes every failure personal.

Opportunity Cost

This is the hardest to measure and the most important.

Every hour maintaining infrastructure is an hour not improving GRC outcomes. Every debugging session is time not spent on actual compliance work. Every dependency upgrade is a feature not built.

I track my time loosely. Rough estimates:

• 40% new features

• 25% maintenance and upgrades

• 20% debugging and fixing

• 15% documentation and support

That 60% not spent on features? On a commercial platform, it would be close to 0%. Someone else handles the maintenance. Someone else debugs the infrastructure. Someone else updates the docs.

The question isn’t whether DIY costs more time. It does. The question is whether you’re getting value from that time that you couldn’t get from a vendor.

The Compounding Effect

These costs don’t add—they multiply.

Scenario: A security patch requires upgrading a core dependency. The upgrade changes behavior in ways that affect two services. Debugging the issue takes longer because you didn’t add correlation IDs. The fix requires updating documentation you never wrote. You deploy on a Friday and discover a production-specific issue. Your weekend becomes incident response.

Each cost alone is manageable. Together, they cascade.

Here’s a real timeline from a “simple” feature request:

Request: Add a new integration (Jamf evidence collector)

That’s 2.3x the expected time. And this was a straightforward feature—no coordination across services, no breaking changes, no security implications.

When DIY Makes Sense Anyway

Despite all this, building GigaChad GRC was right for me. DIY makes sense when:

You have engineering capacity AND long-term willingness. Not just bandwidth to build—bandwidth to maintain for years. The engineer who builds it should want to own it indefinitely.

Your requirements genuinely don’t fit commercial offerings. Not “the vendor is annoying”—actually can’t do what you need. API gating, integration limitations, workflow inflexibility that can’t be worked around.

Vendor lock-in costs exceed maintenance costs. Calculate both honestly. Migration costs are real. So is the 60% maintenance tax on DIY.

You’re building institutional capability, not just a tool. If you’re creating engineering muscle around GRC—capability that compounds—DIY might be an investment. If you just need the compliance checkbox, it’s pure cost.

You enjoy this. Seriously. If maintaining infrastructure feels like a burden, buy. If you find satisfaction in owning the stack, the maintenance cost is partially offset by intrinsic motivation.

I hit all five criteria. Most teams don’t.

When You Should Just Buy

Let me be direct:

Small team without dedicated engineering. If no one wants to own this as their primary responsibility, buy. Part-time maintenance leads to accumulated debt.

Compliance is a checkbox, not a strategic capability. If you just need to pass audits and move on, vendor platforms are optimized for exactly this.

You need it working yesterday. Commercial platforms are deployed in days. DIY takes months to reach parity.

Your vendor’s roadmap actually addresses your needs. Talk to them. Really try to get the feature. Many practitioners skip this step and build instead of asking.

The “premium” features would take you 6+ months to build. Calculate honestly: that API access costing $30K/year would take how many engineering hours to replicate? At fully-loaded engineer cost, the math often favors buying.

The Math

Rough calculation:

• Vendor cost: $100K/year

• DIY build cost: 2 FTE-years (at $150K fully-loaded = $300K)

• DIY maintenance: 0.5 FTE/year ongoing ($75K/year)

Break-even: 4+ years, assuming no scope expansion and consistent maintenance allocation.

If you don’t have specific needs that vendors can’t meet, the vendor usually wins.

Questions to Ask Before You Build

Before you start:

1. Do you have at least one engineer who WANTS to own this long-term? Not assigned to it—actively wants it.

2. Have you actually tried to get your vendor to solve the problem? Escalated to product? Talked to their engineers? Explored workarounds?

3. Can you articulate specifically what you need that vendors don’t offer? Vague frustration isn’t a spec. Concrete requirements are.

4. Do you have production infrastructure experience, or will you learn on the job? Learning is fine—but budget the cost.

5. What happens when that engineer leaves? If the answer is “we’re stuck,” that’s a single point of failure.

6. Are you building a tool or building a product? Internal tool = lower bar. Product for others = dramatically higher bar.

If you can’t answer these confidently, the “biased towards buy” approach is probably correct.

Closing

That LinkedIn commenter was right to push back. “Biased towards buy” is often the right bias.

The GigaChad GRC posts aren’t meant to convince everyone to build. They’re meant to show it’s possible for those who have the right reasons, the right capacity, and the right expectations.

The vendor monopoly is optional. But so is the DIY path.

The best GRC platform is the one that lets you focus on GRC, not on maintaining the platform. Sometimes that’s a commercial solution with good-enough flexibility. Sometimes that’s a custom build you own completely.

Know which one you are before you start.

The author built his own GRC platform and doesn’t regret it—but wouldn’t recommend it to everyone. Still drinks too much coffee.

The original post covered the why—the frustration with vendor lock-in, the six-figure platforms that couldn’t match Google Apps Script, the decision to stop asking permission. But it only scratched the surface of the how. This post goes deeper.

Over the past months, I’ve received pull requests, feature suggestions, and deployment stories from practitioners who’ve actually run this in production. That feedback has validated some architectural decisions and exposed others as premature optimization. Here’s what I’ve learned about building a GRC platform that doesn’t paint you into a corner.

Why Architecture Matters More in GRC

Most software architecture advice assumes you’re building a product with a defined scope. GRC is different. Every organization has a unique control environment, bespoke risk categories, industry-specific frameworks, and auditors with their own preferences. A rigid architecture becomes a straitjacket.

The goal wasn’t to build a platform that handles every use case out of the box. It was to build a platform where adding your use case doesn’t require a fork.

That distinction shaped every major decision.

The Case for Microservices (And When It Actually Makes Sense)

Conventional wisdom says start monolithic, split later. For most applications, that’s right. But GRC has a property that makes early decomposition worthwhile: naturally bounded domains.

Controls are not risks. Vendors are not audits. Policies are not questionnaires. These domains have clear boundaries, different stakeholders, and independent lifecycles. When your auditor asks for changes to the audit portal, you shouldn’t be touching the risk register codebase.

The Domain Boundaries

GigaChad GRC splits into six core services:

Controls - Control library, evidence management, testing
Frameworks - Framework requirements, risk management, assessments
Policies - Policy lifecycle, versions, approvals
TPRM - Vendors, assessments, contracts
Trust - Questionnaires, knowledge base, trust center
Audit - Audit Management, requests, findings, auditor portal

Each service owns its domain completely. The Controls service doesn't know how vendor assessments work. The Audit service doesn't care about policy approval workflows. They communicate through well-defined APIs and a shared event bus when necessary.

What Actually Worked

Independent deployment. When I rebuilt the Audit service to add the external auditor portal—complete with access codes, temporary permissions, and document request workflows—I deployed it without touching any other service. Zero coordination. Zero risk to the control testing that was running in production.

Isolated failure domains. A bug in the Trust service’s questionnaire parsing doesn’t crash risk assessments. Services can be unhealthy independently, and the platform degrades gracefully.

Focused codebases. Each service is small enough to hold in your head. New contributors can understand the Policies service in an afternoon without learning how vendor assessments work.

What Didn’t Work (And What I Changed)

Distributed debugging is painful. When a request touches three services, tracing the failure path requires correlating logs across containers. I added correlation IDs to every request, propagated through the event bus and HTTP headers. Should have done it from day one.

Service discovery added friction. Early on, I was doing manual service location through environment variables. It worked, but adding a new service meant updating every other service’s configuration. Traefik as the API gateway solved this—services register themselves, and routing happens automatically.

Initial setup overhead. Six services means six things to start, monitor, and maintain. For development, I created a single docker compose up that brings everything up correctly ordered. For practitioners who just want to evaluate the platform, there’s now a ./start.sh that handles the complexity.

The Real Lesson

The microservices approach worked because the domain boundaries were clear before I wrote any code. If you’re building GRC tooling and your domains blur together—if you can’t articulate where controls end and risks begin—start with a modular monolith. Microservices are a deployment strategy, not an architecture. Get the boundaries right first.

API-First: If You Can’t Script It, You Haven’t Built It

Here’s a test for any GRC platform: can you create a control, link it to a framework requirement, upload evidence, and mark it tested—entirely through API calls, with no UI?

If the answer is no, you’ve built a dashboard, not a platform.

Every feature in GigaChad GRC is an API endpoint first. The React frontend is just one client among many. This isn’t architectural purity for its own sake—it’s the foundation for everything that makes the platform actually useful.

Why API-First Matters for GRC

Automation scripts replace manual evidence collection. That AWS config you need to pull quarterly? Script it. The GitHub branch protection rules auditors want screenshots of? API call to GitHub, API call to upload evidence, done. The grc-evidence MCP server does exactly this for AWS, Azure, GitHub, Okta, Google Workspace, and Jamf.

AI integration becomes possible. The grc-ai-assistant MCP server uses the platform APIs to provide risk analysis, control recommendations, and policy drafting. It couldn’t exist if the platform required clicking through UIs.

Custom integrations don’t require forks. Want to sync controls with Jira? Pull risk data into your data warehouse? Trigger Slack notifications on audit findings? Build it against the API. Your integration survives platform upgrades.

The MCP Server Architecture

Model Context Protocol servers are the ultimate test of API-first design. They’re external processes that interact with the platform entirely through APIs, enabling AI-powered automation.

Each MCP server is a standalone package that can be used with any AI tool supporting the protocol—Claude, Cursor, custom agents. They consume the platform APIs to:

• grc-evidence: Collect evidence from cloud providers and security tools automatically

• grc-compliance: Run control tests, validate policies, generate reports

• grc-ai-assistant: Provide AI-powered analysis, recommendations, and drafting

The MCP servers proved the architecture. If an external AI tool can operate the platform effectively through APIs alone, the API design is working.

Swagger as a First-Class Citizen

Every service exposes Swagger documentation at /api/docs. This isn’t generated as an afterthought—it’s maintained as part of the development workflow. When someone opens a PR that adds an endpoint, the Swagger docs are part of the review.

The result: practitioners can explore the API interactively before writing any code. No guessing at parameter names or response shapes.

Shared Infrastructure: The Glue That Doesn’t Become Glue Code

Six microservices sounds clean until you realize they all need authentication, database access, file storage, event publishing, and consistent error handling. Duplicate that code across services and you’ve created a maintenance nightmare.

The services/shared/ library is the solution—a TypeScript package consumed by every service, providing:

What’s Shared

Authentication middleware. Keycloak JWT validation, role extraction, permission checking. Every service uses the same @Auth() decorators and guards. Add a new role in Keycloak, and every service respects it immediately.

Storage abstraction. Evidence files might live on local disk, S3-compatible storage (RustFS), or Azure Blob. The shared storage service provides a consistent interface:

Swap backends by changing environment variables. No code changes.

Event bus. When controls need to notify the audit service about test completions, they publish events to Redis. The audit service subscribes without knowing which service published.

This keeps services decoupled while enabling necessary coordination.

Type definitions. Shared TypeScript types ensure the Controls service and Audit service agree on what a “control” looks like. No runtime surprises from schema drift.

Prisma client. One database schema, one Prisma client, consumed by all services. Migrations run once. The schema is the source of truth.

Why a Shared Library Instead of Shared Services

I considered the alternative: dedicated auth service, dedicated storage service, dedicated event service. Each microservice would call these shared services via HTTP.

The problem: latency multiplication. A single request that needs auth, then storage, then events becomes four network hops. For a GRC platform where users are clicking through controls and uploading evidence, that latency compounds into frustration.

The shared library approach means auth happens in-process. Storage calls go directly to the backend. The services share code, not network round-trips.

The Single Database Decision

Yes, all services share one PostgreSQL database. This is controversial in microservices circles, but for GRC it’s pragmatic.

The reality: GRC data is deeply interconnected. Controls link to frameworks. Risks link to controls. Evidence links to everything. Enforcing strict database-per-service boundaries would mean constant API calls between services for basic operations, or maintaining complex data synchronization.

The tradeoff: Services must respect each other’s tables. The Controls service doesn’t write directly to audit tables. This is enforced through code review and convention, not database permissions. It works because the team is small and the domain boundaries are clear.

When to split: If services need to scale independently or you have teams that can’t coordinate, separate databases make sense. For most GRC implementations, the operational simplicity of a single database wins.

Extensibility Without Fork Anxiety

Here’s the scenario that kills most open-source platforms: a practitioner needs something slightly different. They fork. They modify. Six months later, they’re maintaining a divergent codebase that can’t take upstream updates. They might as well have built from scratch.

GigaChad GRC is designed with explicit extension points that don’t require touching core code.

Adding Integrations

The integration architecture follows a consistent pattern. Every integration implements the same interface:

Adding a new integration means:

1. Create a new collector implementing the interface

2. Register it in the collector registry

3. Done

Your custom integration for that weird compliance tool your industry requires? It works the same way as the AWS integration. Submit a PR if it might help others. Keep it private if it’s organization-specific.

Adding Framework Requirements

Frameworks are data, not code. Adding NIST 800-53 or a custom internal framework means:

1. Create a JSON file with requirements

2. Import via the API or seed script

3. Map to existing controls

The platform doesn’t care if it’s SOC 2 or your proprietary framework. The data model is generic.

Adding Services

Need a module that doesn’t exist? The architecture supports adding new services without modifying existing ones:

1. Create a new NestJS service following the established patterns

2. Import the shared library for auth, storage, events

3. Add a Dockerfile following the existing template

4. Register with Traefik via labels

5. The frontend can call it like any other service

The Audit service was added this way after initial launch. Zero changes to Controls, Frameworks, or any other service.

MCP Servers as the Ultimate Extension

For automation that doesn’t fit neatly into the platform, MCP servers provide unlimited flexibility:

• Run on your infrastructure

• Use any language (TypeScript reference implementations provided)

• Consume platform APIs for data

• Integrate with AI tools or run standalone

• No deployment coordination with the platform

This is the escape hatch that prevents forks. If the platform doesn’t do something, script it via API. If you need AI assistance, build an MCP server. The core platform stays maintainable.

Deployment Flexibility: Your Infrastructure, Your Rules

The same codebase deploys three different ways:

Option 1: Terraform for AWS

Full enterprise deployment with:

• VPC with proper isolation (public/private subnets)

• ECS Fargate services with auto-scaling

• RDS PostgreSQL with encryption and automated backups

• ElastiCache Redis cluster

• ALB with SSL termination

• S3 for evidence storage

• Secrets Manager for credentials

Run terraform apply and have production infrastructure in 30 minutes. The Terraform modules are in terraform/modules/ and document every decision.

Option 2: Docker Compose for Single Server

For teams that need production-ready deployment without AWS complexity:

This gives you:

• All services running on one machine

• PostgreSQL, Redis, Keycloak, RustFS included

• Traefik handling routing and SSL

• Automatic health checks and restarts

• Backup scripts included

Many production deployments run this way. A well-provisioned single server handles more load than most GRC programs generate.

Option 3: Managed Infrastructure (Supabase + Vercel)

For teams who want managed services:

• Supabase for PostgreSQL

• Vercel for frontend and serverless functions

• External Redis (Upstash, etc.)

• Cloud storage for evidence

This path trades operational control for operational simplicity.

The Philosophy: Works on My Laptop, Works in Production

The same docker compose up that runs locally runs in production. The same environment variables. The same container images. No “works on my machine” surprises.

The Terraform modules and Docker Compose files aren’t separate configurations—they’re alternative deployment targets for identical containers.

What I’d Do Differently: The Honest Retrospective

Community feedback and production usage revealed decisions I’d reconsider.

Should Have Done Earlier

Correlation IDs from day one. Distributed tracing is painful to retrofit. Every HTTP request and event should carry a correlation ID that flows through the entire request path. I added this after debugging a cross-service issue took two hours.

Feature flags. Some organizations need controls but not risks. Some need TPRM but not audits. Adding feature flags to disable modules without removing code would have made the platform more adaptable. This is now partially implemented but should have been foundational.

Better migration tooling. Database migrations work, but rollback is manual. Organizations upgrading production need confidence that a bad migration won’t require database restoration.

Decisions That Paid Off

API-first from the start. The MCP servers validated this immediately. AI tooling integration was trivial because the APIs were already comprehensive.

Shared library over shared services. In-process shared code keeps latency manageable and deployment simple.

Traefik as the gateway. Automatic service discovery and configuration via Docker labels eliminated a category of configuration management.

RustFS over MinIO. Switching to RustFS for S3-compatible storage reduced resource usage and stayed Apache 2.0 licensed. The storage abstraction made the swap transparent.

Community Feedback That Changed My Thinking

Several practitioners asked for simpler initial deployment—the full microservices setup was intimidating for evaluation. The ./start.sh script and simplified getting-started guide came directly from this feedback.

Others wanted more granular permissions. The initial RBAC model was too coarse. The current implementation supports permissions like controls:read, controls:write, controls:test—fine-grained enough for real organizational structures.

The most repeated request: better documentation for extending the platform. The architecture supports extension, but knowing where to start wasn’t obvious. This post is part of addressing that.

Closing: Architecture as Philosophy

Vendor platforms optimize architecture for their business model. API access becomes a premium tier because restricting it drives upgrades. Customization requires professional services because flexibility cannibilizes support revenue. The architecture serves the vendor.

Practitioner-built platforms optimize for the actual work. APIs are open because automation is the point. Customization is encouraged because every organization is different. The architecture serves the user.

The decisions documented here—microservices along domain boundaries, API-first design, shared infrastructure without shared services, explicit extension points, flexible deployment—aren’t technically novel. They’re the obvious choices when you’re building for yourself instead of building for profit extraction.

That’s the real lesson. Technical decisions compound. Every choice either opens doors or closes them. Vendor platforms close doors strategically—they call it their moat. Practitioner platforms keep doors open because we’re the ones who need to walk through them.

Get Involved

The codebase is on GitHub. The architecture described here is what you’ll find in services/. The MCP servers are in mcp-servers/. The Terraform modules are in terraform/modules/.

If you’ve built extensions, integrations, or just found better ways to do something—pull requests are welcome. If you’ve deployed this in production and have war stories—the GRC Engineering Discord wants to hear them.

The vendor monopoly on GRC tooling was always optional. The architecture to replace it is here.

The author still maintains this platform, still drinks too much coffee, and still believes practitioners build better tools than vendors.

Related Links:

• GigaChad GRC on GitHub

• Building Your Own GRC Stack (Original Post)

• GRC Engineering Community Discord

• GRC Engineering Manifesto

New year, new us! With a new year upon us, I’ve been thinking a lot about what I expect - or maybe just hope - GRC will look like by the end of 2026.

In 2025, the excitement and momentum around GRC Engineering exploded among practitioners and vendors alike.

In 2026, I’m optimistic we will see big leaps forward in how GRC programs, platforms, and tools are designed with GRC Engineering principles and values in mind.

Here’s what I’m hoping this future will look like.

Autonomous GRC

AI will have transitioned from being just a copilot or use case-specific assistant and will instead operate as full fledged agentic extensions of GRC teams.

GRC platforms will provide AI agents that aren’t just confined to work within the platforms they are built in but also will be able to operate outside those platforms too - just like their human counterparts can. Autonomous Security Risk Analysts, Compliance Analysts, Trust Analysts, etc. will exist more and more as agentic AI team members executing core GRC program operations and functions.

Security, safety, and alignment controls and mechanisms will be incredibly important, of course. We’ll see more investment in prompt injection mitigations, tried-and-true human-in-the-loop (HITL) patterns, and AI-native least-privilege access management. It won’t be perfect, but it will be better than it is today and will allow pioneering GRC teams to feel comfortable enough with incorporating autonomous GRC agents into their programs.

I also expect to see more AI agent providers, including GRC platform vendors, obtain AIUC-1 certification and insurance coverage as a way to rapidly build strong assurance for customers (and to better tolerate AI-related risks for themselves) around the safety and security of their AI agents.

Governance

GRC teams will stop treating policies, standards, and procedures as documents to publish and review on an annual basis and instead start treating them as what they were always meant to be: the foundational principles/requirements that security programs are built on and that get systematically integrated into processes and systems.

This means GRC teams will collaborate more with Platform Engineering, Security Engineering, IT Engineering, etc. teams to have 1:1 mappings between security policy/standard requirements and policy-as-code guardrails baked into version control systems, CI/CD pipelines, endpoint/fleet management systems, and runtime monitoring systems.

This also means that de facto policies/standards that non-GRC teams have already implemented in practice will be added to the “law of the land” documentation that GRC teams own. Policies, standards, and controls-in-practice will fully align 1:1 without any disconnects. Furthermore, security awareness training will map 1:1 with security policies, standards, and procedures to ensure workforce personnel are fully aligned on what’s expected of them to uphold their organization’s security program, on day 1 and regularly thereafter.

Risk

Cyber risk quantification (CRQ) becomes a must-have capability for GRC programs. CRQ capabilities will become more prominent in GRC platforms, both for first-party risk and third-party risk management.

We’ll see a convergence and integration between CRQ as a strategic lens for prioritizing security investments, and related tactical security tools/programs, such as full-stack vulnerability risk management (i.e. CTEM, CNAPP, etc.), threat detection & response, cloud security, application security, etc., resulting in a noticeable increase in organizations standing up Risk Operations Centers (ROCs) as the gold standard model for how Risk teams function.

GRC teams will also start to focus much more on first-party risk mitigations in the context of their third-party risk management programs, recognizing they have limited leverage to effect changes within their vendors’ control environments and are better off mitigating third-party risk by implementing first-party controls.

All of these shifts will also drive GRC teams to find automated ways to monitor how their third-party vendor use cases are changing over time to ensure third-party risk exposure is continuously monitored and managed, as opposed to quarterly, semi-annual, or annual reassessments. For example:

• New OAuth-based app integrations setup with an existing third-party system

• New user accounts created in a third-party system using email addresses outside of your organization’s domain

• New IP addresses showing up in third-party system logs that are well-known egress IPs for a widely used SaaS platform

• New sensitive data types being exposed to/accessed by a third-party system that was originally only approved for use with low sensitivity data types

All of these kinds of “use case drift” concerns will be much more easily addressed by GRC teams, in part thanks to new capabilities being introduced in modern GRC/TPRM platforms.

Finally, we will begin moving away from third-party compliance management to a future state of true third-party risk management.

Compliance

“Security Compliance” in the sense of continuous control monitoring and audit operations will hopefully see some additional changes not too different from how much this space has been transforming over the past few years. Rigid control monitoring workflows will be much more customized by GRC teams, whether or not their GRC platforms become much more customizable themselves.

Control monitoring evidence will be fully composable, so that multi-component controls can finally be comprehensively and consistently monitored for operating effectiveness over time. For example: a WAF control must be understood as a combination of proper DNS record configurations, WAF rule configurations, and network/host-based firewall rule configurations in order for it to be properly monitored for operating effectiveness. If a WAF product is implemented, DNS records are properly configured, and WAF rules are configured in blocking mode, but network/host-based firewall rules allow ingress traffic from non-WAF sources, the WAF can be trivially bypassed and thus this control cannot be considered to be designed effectively nor operating effectively.

Trust & Assurance

Similar to how we will see the emergence of the ROC as a new standard for how Risk programs function, we will see the emergence of the Trust Operations Centers (TOCs) as an emerging standard for how Trust programs are designed and function.

Trust programs will be much more tightly integrated with the end-to-end customer experience (i.e. “CX 360”). For example: customer security requirements expressed in the form of contract stipulations will be mapped and tracked by Trust teams with their Sales and Product partners to ensure that these requirements are treated like customer feature/use case requests. Likewise, tracking similar and identical customer security requirements across all customers will reveal a need to change underlying policies and standards across the board, instead of fooling ourselves into thinking we can and should try to commit to e.g. 8 different security incident notification timeframe requirements.

Additionally, Trust Centers will become much more self-service than they are today. Customers won’t have to talk to a human at your organization if they don’t want to. Whatever security questionnaire they have, in whatever format they have it in, can be easily uploaded by a customer into your Trust Center, and then within a few hours or days they will get an email with a secure link to download their filled out questionnaire. Behind the scenes, Trust teams will utilize agentic AI to automatically answer as many questions as they can in these questionnaires (like they are doing today with AI-powered security questionnaire automation tools). HITL will be necessary to answer trickier questions without well-known responses already documented for them. Even if questionnaires live inside TPRM web portals, customers can submit the link to their questionnaire and be instructed to add a specific user account to their TPRM portal all through your Trust Center. Whether through traditional headless browser automation or computer use AI agents, these web portal-based questionnaires can be automatically filled out with high confidence answers with HITL being needed before submitting them back to the customer. In any case, cumbersome email threads, Zoom calls, etc. will become a rarity in this future state, driving better customer Trust Center experiences and more efficiencies for Trust teams.

Lastly, I’m naively hopeful that we will finally start to see some organizations dabble in the world of sharing real(ish)-time control monitoring metrics with their customers to drive stronger continuous assurance with them. This will likely start out as a private sharing mechanism through Trust Center APIs, but will help provide better confidence about a vendor’s controls and also pressure vendors to shore up their control posture between annual/semi-annual SOC 2/ISO audits, thus resulting in stronger control environments that create a rising tide that lifts all boats.

Every GRC professional knows the feeling. You’ve just finished a demo with yet another compliance platform vendor, nodding along as they walk you through their slick dashboards and “enterprise-grade” features. Then comes the pricing breakdown: base platform, per-control fees, evidence automation as an add-on, API access at a premium tier, and reporting locked behind an enterprise license. Basic functionality that should be table stakes—carved up into profit centers.

But the cost isn’t even the worst part. It’s the neutering.

Want to customize a workflow? Submit a feature request. Need to pull data via API for your own analysis? That’s an enterprise feature. Trying to integrate with your existing tooling? Here’s our marketplace of pre-approved connectors. The platforms designed to make GRC teams more effective end up constraining them to the lowest common denominator of capability.

After years of watching vendors monetize mediocrity, I decided to stop asking permission. I built my own.

The GRC Engineering Mindset

Somewhere along the way, I discovered I wasn’t alone. The GRC Engineering Manifesto gave language to frustrations I’d been experiencing for years—the screenshot-based evidence collection that doesn’t scale, the vendor tools built for GRC teams rather than the stakeholders who actually need to use them, the compliance automation that just produces low-value outcomes faster.

More importantly, it validated an idea I’d been circling: practitioners who live these problems daily are better positioned to solve them than vendors chasing market share. When you build something for yourself, you get immediate feedback on whether it actually works. When a vendor builds something, they optimize for demos and renewals.

That reframing—from consumer of GRC tools to builder of GRC solutions—changed how I approached the problem entirely.

What I Built

The final straw came when I realized our six-figure GRC platform was less capable than Google Apps Script, an Excel spreadsheet, and some dirty API calls. That’s not hyperbole—we were literally building workarounds in free tools because the paid platform couldn’t do basic things without tickets and false promises of “coming soon”.

So I built GigaChad GRC. A complete, modular, containerized GRC platform. From scratch. Fueled by caffeine, mass quantities of vibe coding with AI pair programming, aided by some nameless engineers loaned to me to repay a favor, and the very real pain of watching vendors charge extra for functionality that should be table stakes.

The platform is organized into specialized microservices, each handling a distinct domain: Controls and evidence management. Framework assessments with pre-loaded popular framework requirements. Policy lifecycle management with versioning and approval workflows. A full third-party risk management module covering vendors, assessments, and contracts. A trust center for security questionnaires and public-facing transparency pages. And a complete audit management system with an external auditor portal.

Risk management isn’t an afterthought bolted onto a compliance tracker—it’s a full lifecycle system. Risk identification, assessment, treatment, and monitoring with support for quantitative, qualitative, or hybrid scoring methodologies. Interactive heatmaps. Scenario modeling. Treatment tracking with accountability. The kind of risk program that actually informs decisions rather than just satisfying auditors.

Dashboards are fully customizable because I got tired of vendors telling me which metrics matter. You want to see control implementation by framework? Risk distribution by business unit? Evidence collection velocity? Build the view you need, not the view someone else decided was “best practice.”

The platform includes integrated security awareness training with pre-built SCORM packages—no separate LMS purchase required, no per-seat training vendor fees. A full employee compliance suite for policy acknowledgments, training completion tracking, and attestations. 208+ integrations out of the box because GRC doesn’t exist in isolation. Multiple language support for organizations that operate globally. And the most granular role-based access control I’ve encountered in any GRC tool—because “admin or viewer” isn’t a real permission model.

The architecture runs on NestJS microservices behind a Traefik gateway, with PostgreSQL for persistence, Redis for caching, Keycloak for authentication, and MinIO for S3-compatible evidence storage. Everything containerized. Everything designed to be self-hosted in customer infrastructure rather than locked into a vendor’s cloud.

For deployment, I built three paths: Terraform modules for AWS with proper VPC isolation, auto-scaling ECS services, encrypted RDS, and all the enterprise-grade infrastructure you’d expect—deployable in under 30 minutes. A production-hardened Docker Compose setup for teams who just need a single server running in 10 minutes. And a Supabase/Vercel configuration for teams who want managed infrastructure without the AWS complexity. Automated backup scripts, disaster recovery procedures, the works.

The total? Seven microservices—for now. Over 7,000 lines of infrastructure-as-code. Complete API documentation. Production-ready from day one.

Also light mode. Because some of us work near windows.

Could I have spent that time fighting with vendor support tickets and waiting for roadmap features? Sure. But I’d still be waiting.

Best part? If you don’t like it, you can change it. Any part of it. Why? Because there is no one size fits all and I believe that if you pay for something you should be able to do with it what you need. But I thought you said it was free. It is, but if you find create a high quality microservice that may benefit the community I just ask that you toss in a pull request to benefit the community.

Lessons Learned

Microservices aren’t overkill for GRC. The conventional wisdom says start monolithic, split later. But GRC domains are naturally bounded—controls, risks, vendors, audits—and keeping them separate from the start meant I could iterate on one module without touching the others. When I rebuilt the audit service to add the external portal, nothing else changed.

Vibe coding is a force multiplier, not a replacement. AI pair programming got me through the boilerplate faster than I ever could alone. But it couldn’t make architectural decisions or understand why a GRC practitioner needs the risk register to work a certain way. The domain expertise had to come from me. The velocity came from the collaboration.

Self-hosted is a feature, not a limitation. Every enterprise customer I’ve talked to has asked the same question: where does my data live? Building for self-hosted deployment from day one—with proper Terraform modules and production Docker Compose—means the answer is always “wherever you want it.”

Infrastructure-as-code eliminates support nightmares. When deployment is a terraform apply or docker compose up, there’s no ambiguity about configuration. The Terraform outputs tell you exactly what got created. The environment templates document every variable. Customers can deploy consistently without a professional services engagement.

The Tradeoffs

Building a platform is not the same as building automation scripts. This took real time—nights, weekends, the kind of effort that only makes sense if you’re genuinely fed up with the alternatives.

Maintenance is on me. When Keycloak releases a new version or PostgreSQL has a security patch, I’m the one updating the Docker images. There’s no vendor handling that. The same independence that freed me from vendor roadmaps means I own the roadmap.

And there’s no ecosystem. Commercial platforms have marketplace integrations, pre-built connectors, vendor partnerships. I have APIs and the willingness to write code. For some organizations, that’s a dealbreaker. For others, it’s the point.

But here’s the thing—it doesn’t have to be just me. The GRC Engineering community exists precisely because practitioners are tired of waiting for vendors to solve problems we understand better than they do. The innovation, the maintenance, the evolution of tools like this should come from us. Not from product managers optimizing for enterprise ARR. When a practitioner builds a better integration or identifies a gap, that knowledge can flow back to everyone building in this space. That’s the model. Vendors give you a support ticket queue. A community gives you collaborators.

Is This Path Right for You?

Not everyone needs to build a full platform. If your pain is evidence collection, start there—a few API scripts can transform audit prep from weeks to hours. If your pain is workflow rigidity, sometimes JIRA or Notion can do what your GRC tool can’t.

But if you’re staring at a vendor platform that charges extra for APIs, gates basic reporting behind enterprise tiers, and treats every feature request as a professional services opportunity—maybe it’s time to stop asking for permission.

The GRC Engineering community has a Discord and GitHub presence worth exploring. You’ll find practitioners sharing their own tools, comparing approaches, and demonstrating that the vendor monopoly on GRC tooling is entirely optional.

The compliance industry has spent years convincing us that GRC requires expensive, specialized platforms. It doesn’t. It requires clear thinking about risk, evidence of controls, and the discipline to maintain them. How you implement that is up to you.

The author is a GRC Engineering Manager who got tired of waiting for vendor roadmaps.

In-depth continuous assurance over shallow periodic monitoring

This is core value #5 in the GRC Engineering Manifesto. I've been thinking about it a lot lately, especially given all of the dunking on SOC 2 that has happened over the last year, such as all the problems with "compliance commoditization" and "SOC-in-a-box" and who is to blame for it all (Compliance Automation vendors? the AICPA? audit firms? third-party risk management teams? all of the above?!)

There’s a growing chorus of folks in our industry who claim that SOC 2, and the AICPA’s stewardship of it, is thoroughly busted. On the other hand, auditors and CPAs claim that low quality or incompetent auditors are the problem and SOC 2 itself is fundamentally sound.

In my mind, there are valid points on either side of this debate.

But I also think there are deeper issues with SOC 2 (and other security compliance frameworks) that haven't been discussed as much, let alone what it looks like for those issues to be resolved.

In this post, I’m going to lay out what I believe these deeper issues are, paired with a vision for what a better approach could look like for security compliance frameworks to finally provide in-depth continuous assurance about an organization’s security controls.

The problem with SOC 2? It SOCs 2 much!

My first premise on this topic is this: there has never been a time when SOC 2 - or really any industry standard “security compliance audit” - was ever good enough, in any way, shape, or form at providing sufficient assurance about an organization’s security controls.

The fundamental issues with SOC 2’s assurance value predate “SOC-in-a-box” automation products. These issues have been present throughout SOC 2’s history: from SAS 70 being used before the cloud was The Cloud^TM (RIP ASPs); to SSAE 16 establishing SOC as the successor to SAS 70; to SSAE 18 replacing SSAE 16; and all the way up to the 2022 “Revised Points of Focus” update to the 2017 Trust Services Criteria. SOC-in-a box compliance commoditization has merely made it easier to see the deep flaws not just with security compliance frameworks of all kinds.

The deeper issues with security compliance frameworks and audits

Every security compliance framework shares the same fundamental ingredients:

1. A set of requirements or objectives that controls must achieve

2. An audit methodology for determining how well controls meet said requirements

3. A reporting artifact to convey the results of an audit to stakeholders

How these ingredients are implemented vary from framework to framework. But aside from maybe one framework, they all do a poor job at putting these ingredients together in ways that provide in-depth continuous assurance.

Let's unpack the common flaws with each of these one by one.

Control requirements: vague solutions for unclear problems

The biggest issue with how control requirements are implemented is that they are defined without any explicit association or relevance to the threats they are intended to guard against (with the exception of HITRUST - but even it suffers from deeper issues with the other two ingredients I described above).

In the case of SOC 2, control requirements in the form of Trust Services Criteria (TSC) and Additional Points of Focus (PoFs) are so vague that they are virtually useless for ensuring organizations consistently design controls that are proven to be effective at protecting against relevant threats.

Let’s use SOC 2’s Common Criteria (CC) 6.6 as an example:

• CC 6.6 TSC: “The entity implements logical access security measures to protect against threats from sources outside its system boundaries”

• CC 6.6 PoF: “Identification and authentication credentials are protected during transmission outside its system boundaries”

Imagine for a moment if this same kind of requirements framework were used for, let’s say, car safety. In such a bizarro world of vague, loose, and totally optional car safety requirements (which basically existed for ~100 years), it would be like having a TSC stating “the car implements physical restraint measures to protect passengers against threats from abrupt deceleration events” and a PoF stating “passengers are protected during high speed movements on roadways.”

This clearly would be a virtually useless way to not only provide sufficient assurance about the safety of any given car, but to ensure that all cars are equipped with universally-applicable safety measures that protect against common threats that all passengers face.

This has certainly been the case for SOC 2 and other security compliance frameworks. They need to evolve their underlying controls requirements model to be focused on specific requirements that are known to be effective at protecting against common threats.

Audit methodologies: 20th century approaches applied to 21st century systems

This is the area that SOC 2 and other security compliance audits get criticized about the most: point-in-time screenshots, hours upon hours of walkthrough meetings, and quarterly lookback reviews all make the audit world go ‘round.

While these tend to be the most frustrating and inefficient aspects of audits for those who undergo them, I find that these are not the most problematic aspects of how current audit methodologies severely limit the assurance value such audits can provide. The biggest shortcoming with our security compliance audit methodologies is that we almost never assess historical evidence for technical controls’ operating effectiveness. This can result in huge misses about the reality of an organization’s’ control operating effectiveness which is best summed up with this meme:

Not only that, but auditors still primarily use evidence sampling methods (both statistical and nonstatistical) to draw conclusions about control operating effectiveness. However, there have been long-running concerns within the accounting profession with how auditors exercise too much professional judgment, rather than more strictly sticking to rigorous statistical principles, when determining what kinds of sampling methods to use and how to apply them. This can create excessive risks with drawing inaccurate conclusions about control operating effectiveness.

Now you might be thinking, “wait, my auditors always ask for samples of control evidence that include past dates during my audit period!” - and to that I would say: yes, you’re correct!

But this usually is only done for process controls that are inherently transactional in nature. For example: access requests, access (de)provisioning events, change requests, etc. which are operated via ticketing systems which necessarily means there is always historical evidence of a control’s operations.

However, technical controls that are inherently stateful in nature, such as at-rest data encryption, endpoint detection & response (EDR) tooling, or web application firewalls (WAFs), are only assessed by auditors for their current state. It doesn’t matter how long your audit period is - it could be 1 month, 6 months, or 12 months - your technical controls’ operating effectiveness is not being properly tested.

Why might this be? Well, a lot of organizations likely aren’t maintaining a historical audit trail of their technical controls’ state over time, and for whatever reason most auditors don’t think to push their clients to provide such historical evidence, even as an opportunity for improvement to implement before the next audit happens.

We need to change our audit methodologies to fully cover historical control operating effectiveness during the entirety of an audit period and to analyze the full population of a control, especially for technical controls. Otherwise, we’re only providing (very weak) assurance about controls’ operating effectiveness for the brief moment in time we gather evidence about their state.

Reporting artifacts: static documents for providing assurance about dynamic environments

Take a look at the results from this very unscientific poll I conducted on LinkedIn to gauge what our profession thinks the “use by” date for your SOC 2 Type II report should be before its assurance value expires. The results are fascinating:

It’s shocking that anyone thinks that a SOC 2 Type II report provides sufficient assurance up to 12 months after it is issued. Modern software-as-a-service organizations are making dozens, hundreds, and even thousands of changes to their systems every day. Every change poses varying risk to the operating effectiveness of the controls that exist in and around said systems: entire workloads deployed without threat detection controls in place (ouch!), new data stores deployed without at-rest encryption enabled (oops!), or a new web API released on a domain that your WAF isn’t configured to protect (oof!).

Now let’s take into account the fact that it can take weeks to go from the last piece of evidence being reviewed by your external auditor and your SOC 2 Type II report being finalized. Why do we treat this status quo of security compliance reporting artifacts as having any assurance value more than 1 week after they’ve been finalized?

We need a new kind of reporting artifact that is dynamic enough to reflect the current, and historical, operating effectiveness of an organization's controls. Static PDFs aren’t gonna cut it anymore.

A vision for security compliance audits that provide true in-depth continuous assurance

The problems with our current security compliance audit frameworks are clear: control requirements are very vague and not explicitly threat informed, audit methodologies are way too narrowly focused, and static reporting artifacts quickly become outdated views of highly dynamic control environments.

To overcome these fundamental flaws with SOC 2 and other security compliance frameworks, I’d like to propose a new framework for providing in-depth continuous assurance about an organization’s controls viability and operating effectiveness.

This framework:

1. Should have specific control requirements that are explicitly related to relevant threats

2. Should facilitate and require comprehensive control auditing methodologies that match the scale and depth of modern organizations’ control environments

3. Should provide a reporting artifact that is as dynamic as the control environments for which it is intended to describe the operating effectiveness

I call this framework ALCOVE: Assurance Levels for Control Operating Viability & Effectiveness.

Rather than totally reinventing the wheel, I believe we should draw inspiration from wheels that have already been invented from similar disciplines within security and software engineering. There already exists a scalable and robust security assurance framework that is being adopted by software providers, large and small, across various industries: Supply-chain Levels for Software Artifacts, or SLSA ("salsa") for short, which is a software supply chain security assurance framework.

Similar to SLSA, ALCOVE has various levels of assurance that an organization can strive to provide, allowing for flexibility for organizations and their stakeholders alike to provide and require establishing certain levels of assurance based on their specific needs.

Here’s what it could look like to integrate ALCOVE with SOC 2:

SOC 2 Type I and Type II reports would still exist in this world and still provide (limited) value for organizations and their stakeholders. However, we can extend SOC 2 report types to Type III and Type IV so SOC 2 can provide higher levels of assurance in line with ALCOVE Level 3 and Level 4.

In order for this to truly overcome the three fundamental flaws I outlined above, we need to also evolve our control requirements and reporting artifacts.

In the world of ALCOVE, SOC 2’s TSCs would be more rigorous, incorporating Common Threat Criteria and Common Mitigation Criteria to ensure organizations are implementing relevant controls that are well known to protect against relevant threats so that sufficient assurance can be clearly and unambiguously provided about control operating effectiveness. Here’s an example of what that could look like - the text in black below is existing text from SOC 2’s TSC language, and the text in red are the additional ALCOVE-related control requirements:

Finally, we need to revamp our security compliance reporting artifacts so they’re as dynamic as the control environments we’re trying to provide in-depth continuous assurance around. In addition to providing an audit report, with rich context about an organization’s system, architecture, controls, and an auditor’s opinion about control operating effectiveness, we also need control operating effectiveness metrics that capture current and historical operating effectiveness. Much in the same way that StatusPage created a new paradigm for providing transparency around an organization’s system uptime and availability, an ALCOVE-specific reporting artifact would look something like this:

While existing Trust Center products on the market today provide Key Control Indicator (KCI) metrics about an organization’s controls, they are, quite frankly, junk. They only tell you what the “current state” of an organization’s controls are like. And in some cases, certain Trust Center products will hide/remove a control (and its corresponding green checkmark) when the control is in a failing state. This is pure unadulterated security assurance theater. In order for real-time control operating effectiveness dashboards to truly provide in-depth continuous assurance, they must provide an honest representation of an organization’s controls, both current and historical states.

As excited as I am about how a framework like ALCOVE could help provide stronger assurance about control operating effectiveness, there is a big obstacle to adopting a more rigorous approach like it: incentives.

Overcoming the obstacle of misaligned incentives

Right now, incentives around security compliance audits are skewed in the wrong direction: many organizations, especially smaller and newer companies, are incentivized to pursue cheaper and weaker audits that don’t sufficiently scrutinize their controls. This distorts market signals about organizations’ risk profiles, especially when third-party due diligence teams rely on basic compliance requirements to “allow” vendors into their environment (“Do you have a SOC 2 Type II without a qualified opinion or any exceptions? Ok, great, now answer these 500 other questions about your security practices - be honest! If your answers look good enough, you’ll win our $200k ARR contract.” Let’s not kid ourselves: these incentives are so horribly misaligned.)

Additionally, third party security risk management teams aren’t usually empowered to make risk-taking decisions for other stakeholders at their organization, who are looking to use a vendor solution due to the outsized value they stand to gain from doing so. Third party security risk assessments are typically highly inefficient and take too much time to get to a decision about whether or not to proceed with a vendor given their risk profile. Teams that take weeks to assess a vendor that they would then want to say “no” to because of weak security controls will get bulldozed over by leaders at their organization. In so doing, they will burn through political capital, undermining trust in their team and function across their organization which can create feelings of job insecurity. In other words: third party security risk management teams have neither the leverage nor incentive to say “no” to a vendor that provides weak assurance about their security controls.

One way we could course correct incentives in this dynamic? By better integrating cyber insurance into the mix!

Here’s what the current state of our “security assurance & insurance” dynamic looks like in the world:

The incentives that exist in this dynamic are as follows:

• Auditors want to grow their customer base and make more money, meaning they want to avoid upsetting their customers with lengthy cumbersome audits that could result in them getting a “failing grade.”

• Customers are of two minds: the actual customer team for a vendor’s solution wants to get their hands on said solution ASAP. Third-party risk management teams are encumbered by contradictory fears: the fear of approving an overly-risky vendor (which if said vendor experiences a security incident, third-party risk management teams fear they will be held accountable for making a bad risk decision); and the fear of saying “no” resulting in backlash from the customer team.

• Vendors want fast, easy, and cheap audits so they can win more business and keep their sales cycle running efficiently.

• Insurance providers want to grow their customer base and make more money while reducing uncertainty about the risk pool they’re managing, such that they reduce the likelihood and size of claim payouts.

At the end of the day, all players are motivated by two fundamental incentives: spend less resources to get more value.

So what would a better model look like where incentives are better aligned in a way that actually could drive improved controls across organizations through stronger assurance signals being provided by vendors to other stakeholders?

I am going to draw inspiration for this idea from two sources: the Artificial Intelligence Underwriting Company, which is pioneering a novel AI Assurance + Insurance framework called AIUC-1 (which, you may notice, is very ALCOVE-esque); and Progressive Insurance’s Snapshot offering, which allows drivers to get discounts on their car insurance while allowing Progressive to reduce uncertainty about their risk pool via automated continuous monitoring of driving behavior.

Now the incentives change, driven largely by insurance providers who have the most leverage of any other stakeholder in this picture. All organizations currently have a strong incentive to transfer cyber risk to insurance providers in order to avoid experiencing catastrophic losses (for example, through extensive outages and system disruptions caused by ransomware).

Insurance providers have a great opportunity to push vendors to automatically and continuously feed them evidence about their controls, instead of gathering context via questionnaires once per year.

Vendors stand to save money on their cyber insurance premiums with the same, or potentially better, coverage, which of course requires them to ensure their controls are continuously operating effectively!

Auditors stand to have an easier time performing faster, more efficient and more rigorous audits.

Customers stand to gain stronger assurance, at the time they perform due diligence and continuously thereafter.

Did I just solve all of the world’s cybersecurity problems???

(I kid, I kid)

In conclusion

All of this is very much wishful thinking on my end. But we as a civilization have achieved crazier things in less opportune circumstances (see: sending humans to the Moon and back in a fancy metal pressurized can using 1960s-era technology).

What do you think of this? What seems like it would work or not work about these ideas? What would make it more viable?

Subscribe now