Stop Buying Compliance Theater: A Practical Checklist
GRC Platform Evaluation Checklist
A practical guide for choosing compliance automation tools and auditors that actually deliver real security, not performative theater.
If you came here from my LinkedIn/Substack post, welcome. This is the detailed version with everything you need to evaluate a GRC platform and auditor before committing your budget, your reputation, and potentially your personal liability.
I’ve spent 12+ years in security across SaaS unicorns, ecommerce, startup/scaleup SaaS, banking/fintech, and national CERT operations. I’ve built and audited real controls. I’ve also seen too many organizations burn money on tools and auditors that give them a certificate and nothing else.
This checklist is what I use. Feel free to adapt it.
1. Do your homework on the vendor first
Before you evaluate features, evaluate the company behind them. Marketing will always sound good. Your job is to look past it.
What to check:
Don’t rely on how long the platform has been around or who funded them. Dig deeper. Look for independent reviews on Reddit (r/soc2, r/cybersecurity), G2, and LinkedIn. Search for complaints, not just praise.
Ask peers in your network who have actually used the platform. Not people who saw a demo. People who went through a full audit cycle with it.
Look at who their clients are. Can you verify those claims independently, or is it just logos on a website?
Check how they handle criticism and complaints publicly. Do they engage transparently or deflect?
If they name-drop big clients repeatedly during sales to build credibility, ask those clients directly about their experience if you can.
Red flags:
No verifiable client references beyond what’s on their website
Aggressive sales tactics with pressure to sign quickly
Dismissive responses when you ask hard questions during the sales process
2. How does it collect evidence?
This is the single biggest differentiator between a real GRC platform and a template pack with a SaaS wrapper. Everything comes down to how evidence gets into the system.
What to check:
During the demo, ask to see a specific integration end-to-end. Watch whether it pulls real data or asks you to upload screenshots into a form.
Does the platform have real API integrations with your stack? This means your cloud provider (AWS, GCP, Azure), ITSM (Jira, ServiceNow, etc.), SSO, HRIS, code repositories (GitHub, GitLab, etc.), SIEM, and vulnerability management tools.
Ask directly: “For each integration, what percentage of evidence is collected automatically vs. manually?” If they can’t give you a number, that’s your answer.
For each integration, ask what specific data points it collects. A real integration should pull evidence directly relevant to audit controls: security configurations, access policies, logging settings, enforcement status. Not just confirmation that a tool is connected.
Ask how integration data maps to specific controls. Can you see which control each piece of evidence supports? Or is it a generic data dump with no clear mapping?
During trial, connect all your major tools and see how it actually gathers evidence. Test with your real cloud environment, your real ITSM, your real SSO. Don’t evaluate based on a canned demo.
What happens between audits? Does the platform provide continuous monitoring and alert you when controls drift out of compliance, or does it go silent until next audit season?
Red flags:
“Integrations” that are just form fields where you paste screenshots
Large integration counts advertised without clarity on what those integrations actually do or what data they pull
Evidence that looks the same across the demo regardless of what tools you connect
No ability to demo with your actual stack during trial
No continuous monitoring or drift detection between audit cycles
3. How independent is the auditor?
The relationship between the platform and the auditor is where the biggest structural risks hide. This isn’t a nice-to-have. AICPA standards require genuine independence, and the 2022 update to the SOC 2 Guide specifically emphasized the threats created when lines between GRC platforms and audit firms blur.
What to check:
Can you choose your own auditor, or does the platform lock you into their partner? If you can only use their auditor, ask why.
How many audit firms are in their network? A healthy platform works with multiple reputable, independently recognized firms. If it’s one or two unknown firms, that’s a concern.
Can you bring your own auditor and use the platform purely for evidence management and control monitoring? A good platform should support this. If they resist, ask yourself why.
Is the audit firm genuinely separate from the platform company? Check ownership, leadership, and corporate filings. If the same people or entities own both, that is a structural conflict of interest.
Ask: “Does the auditor design their own test procedures, or does the platform provide them?” The correct answer is that the auditor designs them independently.
Red flags:
You are not given a choice of auditor or the platform strongly pushes one specific firm
The platform’s auditor network is limited to one or two firms that are not independently well-known in the industry
When you ask about auditor independence, you get vague reassurances instead of clear answers about corporate structure and separation
The platform discourages or makes it difficult to bring your own auditor
Auditor relationship details are not transparent and you can’t find clear information about the audit firm’s accreditation, peer reviews, or track record independent of the platformach integration collects and how it maps to specific controls
4. Can you trust the evidence?
Evidence integrity is what separates a defensible audit from a house of cards. If evidence can be fabricated, tampered with, or pre-populated without anyone noticing, the entire compliance process is meaningless.
What to check:
Does the platform show when each piece of evidence was collected, with timestamps?
Is there a chain of custody showing which integration produced the evidence and when?
Can evidence be manually overwritten or replaced after collection? If yes, is there a log of that change with reasoning?
Are there tamper-detection mechanisms like hashing or immutable logs?
Can the auditor independently verify that evidence came from the claimed source and not from a manual upload?
Is there a clear separation between evidence that was automatically collected through integrations and evidence that was manually uploaded? Both may be legitimate, but the distinction should be visible.
Red flags:
Evidence is stored as flat files with no metadata about origin or collection time
No audit trail for changes to evidence
The platform allows clients to modify evidence after the observation period without logging
Evidence that exists in the platform before you’ve done any actual work, especially for activities that require real organizational effort like governance reviews, tabletop exercises, risk assessments, or security simulations
5. Does it build real policies or template theater?
A GRC platform should help you build a security program that reflects your actual organization. If it hands you a stack of generic documents and calls it done, it’s not a compliance tool. It’s a template shop.
What to check:
Are policies generated from templates as-is, or does the platform guide you through creating policies that reflect your actual organization?
Do the default policies reference tools or processes your organization doesn’t actually use, like endpoint management platforms you haven’t deployed or testing you haven’t performed?
Does the risk assessment reflect your actual business, or is it a generic list of default risks that aren’t specific to your industry, technology stack, or threat landscape?
Can you customize controls based on what you’ve actually deployed, or are you forced into a one-size-fits-all framework?
Does the platform support policy versioning with approval workflows? Can you see who approved each policy, when, and what changed?
How does the platform handle exceptions and risk acceptance? Can you formally document and track accepted risks with justification and review dates?
If you pursue multiple frameworks (SOC 2, ISO 27001, HIPAA), can controls map across frameworks without duplicating effort?
Red flags:
You can achieve “100% compliance” in days without doing any real work
Policies reference tools or processes your organization doesn’t actually use, like endpoint management solutions you haven’t deployed, testing methodologies you haven’t performed, or incident response procedures that don’t match your actual team
The platform recommends you “adopt as-is” for all policies without customization
No support for policy versioning, change tracking, or approval workflows
No way to formally document risk acceptance or exceptions
No cross-framework mapping, forcing you to duplicate effort across certifications
The test:
Pull any two policies from the platform. Read them. Do they reference your actual tools, your actual processes, your actual team structure? Or could they belong to literally any company? If it’s the latter, it’s a template pack with a SaaS wrapper.
6. Who writes the audit report?
This is non-negotiable. The compliance automation tool’s job is to provide an auditor-client engagement platform, evidence gathering and presentation, control monitoring status, and GRC documentation. It is NOT the tool’s job to generate reports on behalf of the auditor. If it does, the entire attestation is compromised.
What to check:
Does the platform generate any part of the audit report? Ask this explicitly before purchasing.
Who writes the auditor’s conclusions, test procedures, and test results? The answer must be: the auditor.
Does the platform provide a “draft report” to the auditor for review, or does the auditor produce the report independently using evidence from the platform?
Red flags:
The platform provides “draft” reports with auditor conclusions already written
Reports from different clients on the same platform have identical test procedures and conclusions
The same template language or errors appear across multiple reports
The auditor’s credentials or license numbers are pre-embedded in the report before the auditor has reviewed anything
7. How to evaluate the audit firm
Even if your platform is solid, a weak auditor can undermine everything. This section is about evaluating the firm itself, independent of whatever platform you use.
What to check:
SOC 2: The firm must be a licensed CPA firm. Verify through your state’s Board of Accountancy or the AICPA directory. Check individual auditor certifications (CPA, CISA) and the firm’s peer review history.
ISO 27001: The firm must be an accredited certification body. Check accreditation through ANAB (US), UKAS (UK), DAkkS (Germany), or your national accreditation body under ISO 17021. Confirm they conduct proper Stage 1 and Stage 2 as separate engagements. A quick verification: an accredited ISO 27001 certificate will carry both the accreditation body mark (ANAB, UKAS, DAkkS) and the IAF seal. If those marks are missing, the certificate may be from a non-accredited body and could be rejected by your clients or partners.
HIPAA: There is no formal HIPAA certification from HHS. However, HITRUST CSF (particularly the r2 validated assessment) is widely recognized in the healthcare industry as the standard for demonstrating HIPAA compliance. If a vendor claims 'HIPAA certified' without specifying HITRUST or another recognized framework, ask what exactly they mean.
GDPR: There’s no single “GDPR certification” either. Look for data protection expertise, familiarity with relevant supervisory authorities, and ability to assess both technical and legal requirements. ISO 27701 certification is a credible privacy-specific option if the certification body is accredited for it.
Across all frameworks: ask for a sample report or assessment output. Read it. Does it describe specific test criteria, name specific samples examined, and document specific findings? Or could it belong to any company?
Where are the auditors actually based? If anyone claims a specific geography, verify independently.
How does the firm handle findings? A credible auditor will flag issues. If they promise a clean report or guaranteed certification before looking at anything, that tells you everything.
Red flags:
Unknown firms with no verifiable track record in the industry
Auditors or assessors without relevant active credentials for the framework being assessed
Reports that use identical language across different clients regardless of framework
Guaranteed pass, guaranteed certification, or “compliant in days/weeks” as part of the sales pitch
One firm claiming to certify you across every framework with the same team and methodology
Test conclusions that say “no exceptions” for every area without describing what was actually examined
8. Your personal liability
This section is not here to scare you. It’s here because most people responsible for security and compliance don’t realize the personal exposure they carry.
Know this:
Under HIPAA, false pretenses carry fines up to $100,000 and imprisonment up to 5 years. If PHI is compromised because compliance was faked, the person responsible for security is often the first one investigated.
Using fabricated audit reports or faking compliance to win enterprise deals can constitute wire fraud under federal law.
Beyond criminal exposure, faking compliance creates breach of contractual obligations with every customer whose contract includes compliance representations. This leads to penalties, breach of trust, reputational damage, and legal liabilities that can outlast the original fraud by years.
Your signature on management assertions and attestation letters means you are personally vouching for the accuracy of what’s in that report.
When breaches happen, forensic investigators look at who signed off on what. “I didn’t know the platform was faking it” is not a defense when you never verified.
What to do about it:
This is not about walking away from your job. This is about fighting for real security from within. Push back on management. Educate leadership on the real risks, not just the compliance checkboxes. Build meaningful programs even when the budget is tight. Document your objections when overruled.
That is what this profession demands from us.
Final Word
Compliance is an infrastructure, not a template-driven checklist. It should be baked into the product and the business, adhered to and monitored day to day, from design to finish.
If you found this useful, follow me for more on cybersecurity, compliance, and security due diligence:
More coming soon.