Introducing GRC Engineering: A New Era of AWS Compliance

Introducing GRC Engineering: A New Era of AWS Compliance

Speakers: AJ Yawn

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=nEM7z266D6o

Overview

AJ Yawn, Director of GRC Engineering at Aquia and author of the "GRC Engineering for AWS" book, presented a passionate manifesto for transforming governance, risk, and compliance (GRC) from a manual, screenshot-driven, auditor-appeasement function into an engineering discipline that builds compliance directly into the cloud technology stack. The talk combined a pointed critique of the current state of SOC 2 auditing -- which Yawn called "a joke" -- with a concrete technical walkthrough of building a self-documenting compliance system using AWS Audit Manager, Security Hub, Config, CloudTrail, and Lambda. The core argument: GRC professionals must become technical practitioners or face extinction, and compliance must shift from periodic manual evidence collection to continuous automated verification.

Background

▶ Watch: The Toby from The Office problem: how GRC professionals are perceived (2:00)

Yawn's critique of the GRC profession draws from nearly a decade of experience, starting as a SOC 2 and ISO auditor in 2017. The fundamental problem, as he frames it, is that GRC has not evolved alongside the security industry. While AppSec, IAM, and DevSecOps have made significant advances over the past eight years, GRC professionals are still collecting screenshots, asking engineers to sit in rooms with auditors, and producing compliance artifacts that nobody reads or trusts.

SOC 2, the most widely used compliance framework for startups and mid-size companies, exemplifies the dysfunction. Companies contractually require SOC 2 reports from vendors. The reports are produced as large PDFs filled with accounting language. Nobody reads them. Nobody understands them. Yet security decisions are made based on their existence. The auditors ask questions disconnected from actual security practices, and engineers -- expensive resources who should be shipping product -- are pulled away from their work to answer them.

The emergence of GRC engineering as a role and discipline represents an attempt to break this cycle. Companies are increasingly hiring GRC engineers -- hybrid professionals who understand both compliance frameworks and technical implementation. Yawn fears, however, that the profession faces an existential threat: if GRC professionals don't develop technical skills, organizations will simply empower existing security engineers and DevOps practitioners with compliance training and AI tools, eliminating the need for dedicated GRC staff.

Key Findings

▶ Watch: GRC engineering defined: building compliance into the tech stack (6:00)

The talk's central demonstration was a self-documenting cloud compliance system built entirely with AWS native services. The scenario: a new GRC director at "FAFO Inc." inherits a failed SOC 2 audit (three engineers quit from auditor interactions), no budget for a GRC tool, 10 AWS accounts, and three weeks to deliver a SOC 2 Type 2 assessment.

The solution leverages the existing security infrastructure that the DevSecOps team already had in place: CloudTrail for API logging, AWS Config for configuration tracking, Security Hub with CIS Benchmarks and Foundational Security Best Practices, all feeding into a central security account.

On top of this, the GRC engineer deploys AWS Audit Manager with a custom framework -- not the default AICPA SOC 2 control set that nobody understands, but controls written in language that makes sense for the organization. Audit Manager is configured with data sources from Security Hub (for compliance status), Config (for historical tracking), and CloudTrail (for API activity). Within 24 hours, automated evidence begins flowing into every control.

The innovation extends to SDLC evidence. Instead of pulling engineers into auditor meetings, the system takes outputs from existing GitLab CI/CD pipeline scans (SAST, DAST, dependency scanning) and converts them to Amazon Security Finding Format (ASFF) for ingestion into Security Hub and Audit Manager. Every code push that reaches production generates compliance evidence automatically, without any engineer interaction.

A Lambda function (called an "evidence harvester") runs weekly to extract evidence from Audit Manager, format it into an Excel spreadsheet (the "auditor-friendly report"), and optionally feed it into a DynamoDB table visualized through QuickSight dashboards. Auditors also receive a least-privilege IAM role for direct access to Audit Manager evidence folders.

Technical Deep Dive

▶ Watch: AWS Audit Manager with custom frameworks and automated evidence collection (12:00)

The architecture uses a hub-and-spoke model common in AWS multi-account setups. Security Hub, Config, and CloudTrail evidence flows from 10 AWS accounts into a central security account. Audit Manager sits in this central account and creates daily evidence folders for each control. Evidence types include:

• Security Hub findings: Automated compliance checks (pass/fail status for specific rules)
• Config rules: Historical configuration tracking that eliminates auditor sample requests -- you can show continuous compliance over time rather than point-in-time snapshots
• CloudTrail events: API call records for change tracking and access logging
• ASFF-formatted CI/CD scan results: SAST, DAST, and dependency scan outputs from GitLab pipelines converted to Security Hub's native format

The custom framework design is critical. Rather than mapping directly to AICPA TSCs (Trust Services Criteria), the GRC engineer writes controls that describe what the organization actually does in language both engineers and auditors can understand. The data sources for each control are explicitly mapped to Security Hub rules, Config rules, and CloudTrail event types.

When a CI/CD scan fails (a genuine security finding), it flows into Security Hub as a finding and enters whatever remediation workflow the organization has in place. When it passes, the passing evidence feeds into Audit Manager for the auditor. This dual path ensures both security operations and compliance evidence are served by the same data pipeline.

Demo / Proof of Concept

▶ Watch: Converting GitLab CI/CD scan outputs to ASFF for compliance automation (14:00)

No live demo was performed. Yawn showed screenshots of the AWS Audit Manager interface, including evidence folders with daily automated evidence collection, Security Hub evidence flowing into controls, and the structure of the Lambda-generated Excel reports for auditors.

Defensive Implications

▶ Watch: Core principles: continuous automation, enable engineers, evidence quality (20:00)

The implications are primarily organizational and process-oriented rather than technical. For GRC professionals, the message is adapt or become obsolete: learn the cloud platforms your organization uses, understand CI/CD pipelines, write Python, and stop hiding behind frameworks and policies. For security leaders, the message is to invest in GRC engineering roles that bridge the gap between compliance theory and technical implementation. For engineers, the message is that a good GRC engineer will protect your time by automating evidence collection rather than pulling you into auditor meetings.

Specific recommendations include:

• Build custom Audit Manager frameworks with controls written in organizational language, not raw AICPA criteria
• Use existing security tooling (Security Hub, Config, CloudTrail) as automated evidence sources rather than deploying dedicated GRC platforms
• Convert CI/CD scan outputs to ASFF format for ingestion into the compliance evidence pipeline
• Create least-privilege auditor IAM roles for direct evidence access
• Focus on evidence quality (automated, testable, verifiable) over evidence quantity (number of controls)
• "Live off the land" -- learn what tools your engineering team already uses before introducing new ones

Key Takeaways

• SOC 2 in its current practice has become disconnected from actual security, relying on screenshots and manual checks that prove nothing
• GRC engineering embeds compliance into the technical stack through continuous automated evidence collection, eliminating the need for periodic manual audits
• AWS native services (Audit Manager, Security Hub, Config, CloudTrail, Lambda) can build a complete self-documenting compliance system without third-party GRC tools
• CI/CD pipeline outputs can be converted to ASFF format and fed into Security Hub and Audit Manager, automating SDLC compliance evidence
• GRC professionals who do not develop technical skills face career obsolescence as AI can already handle the document-reading and framework-mapping tasks that define much of current GRC work
• The core principles are: continuous automation over periodic manual work, enable engineers versus burden them, empower auditors versus manage them, and evidence quality over quantity

About the Speaker(s)

AJ Yawn is the Director of GRC Engineering at Aquia and the author of "GRC Engineering for AWS," released the same day as his talk. He previously founded a compliance automation company, taught at the SANS Institute on cloud compliance, and has been a SOC 2 and ISO auditor since 2017. He is an outspoken advocate for modernizing the GRC profession and is active on LinkedIn where his critiques of SOC 2 practices generate significant discussion.