I have been reading the second edition of Observability Engineering (2nd Edition) by Charity Majors, Liz Fong-Jones, and George Miranda. It is one of the best technical books written I’ve read this past year. And the more I read it, the more I am convinced that observability and compliance are trying to solve the same fundamental problem.

Observability exists because understanding the true state of a software system is hard. Systems are too complex, too distributed, too dynamic to understand through static snapshots or pre-defined thresholds. Engineers needed a way to ask arbitrary questions of actual runtime data. So they built observability: the ability to understand any internal system state by examining its external outputs.

Compliance exists because understanding the true state of your control environment is hard. Controls are too distributed, too dependent on actual system behaviour, too dynamic to understand through annual audits and attestation forms. GRC professionals need a way to ask arbitrary questions of actual operational data.

These are the same problem. One discipline solved it. The other has not. Yet.

IN PARTNERSHIP WITH

The 5 Step Framework for Building GRC Agents

Your GRC workflow has six approval checkpoints and your compliance program has 847 controls, but your team has the same headcount it had three years ago. Sounds like a math problem with no good answer, right? Well... Anecdotes built a 5-step framework for replacing those workflows with agents that handle the work autonomously and only pull humans in when it actually counts.

The Shape of Your Data Constrains the Questions You Can Ask

There is a line in the book that should change how every GRC professional thinks about evidence:

"The shape of the data you collect constrains the questions you can ask later."

Think about how most GRC programmes collect evidence today. Screenshots of dashboards. Attestation forms filled out quarterly. Manual exports from security tools. PDFs of configurations. Evidence packages stitched together once a year so an auditor can sample 0.07% of your environment and call it "certified."

The shape of that data is flat, static, and lossy. 

You can only answer the questions you predicted in advance. If the auditor asks something you did not anticipate, you scramble. If leadership asks "are we compliant right now, not last quarter," you cannot answer with confidence. You pre-decided the shape of the data, so you pre-decided the investigation.

Meanwhile, your engineering team already collects continuous, structured, queryable data about every deployment, every access change, every configuration modification, every API call, every infrastructure event. That data lives in your observability and monitoring stack. Datadog. Grafana. Splunk. CloudWatch. Your SIEM. Your CI/CD pipeline logs.

Your compliance evidence already exists. You built a parallel system to collect it again.

GRC Has a Three Pillars Problem

In observability, there is a well-documented failure pattern. Engineering teams historically stored logs in one tool, metrics in another, and traces in a third. When something broke, responders had to manually correlate between three separate data stores. That cognitive overhead slowed investigations and led to misdiagnosis.

The observability community solved this by unifying telemetry into a single data store: one structured event per unit of work, queryable in any dimension after the fact.

GRC has the exact same fragmentation. Evidence lives in one platform. Risks in another. Controls in a third. Audit findings in a fourth. Policy documents in a fifth. When you have a question that crosses those boundaries, you stitch things together manually.

The Central Data Layer newsletter explored this from the GRC architecture perspective. The observability lens takes it further: the unified data layer you need for compliance already exists in production.

The Closest Thing to Source of Truth

Your production systems, your observability stack, your monitoring infrastructure: that is the closest you will ever get to source of truth about how your technology actually works in practice. Not your GRC platform. Not your risk register. Not your control matrix.

Production teams, platform teams, and security teams already use telemetry to make real-time decisions. They trust this data enough to page someone at 3am. They trust it enough to trigger automated rollbacks. They trust it enough to bet the reliability of the business on it.

If that data is trustworthy enough for production engineering, it is trustworthy enough for compliance evidence. The question is whether GRC teams know how to read it.

In the State of GRC 2026 report (795 respondents), the average GRC professional rated their own technical skills 5.4 out of 10. 73.6% of CISOs use no commercial GRC tool. The number one tool is still a spreadsheet.

Those numbers tell a story. The data exists. The tooling to query it exists. The gap is in the people who bridge GRC and engineering, and the skills they carry.

Compliance Is Observability Applied to Controls

This is not a metaphor. This is the natural evolution of where compliance was always heading when you take its primitives to their logical ends.

If you can surface all events related to any particular system, and you need to apply specific controls on that system, you can review any change to that system through the observability stack. You can test controls continuously rather than annually. You can answer questions you did not predict, because the underlying data is structured and queryable.

This is the difference between a questionnaire and a query. A questionnaire asks a human to attest. A query asks a system to prove. The future of GRC evidence collection is queries, not questionnaires.

I wrote about compliance by construction versus compliance by inspection last week. Construction is about build-time: baking compliance into how infrastructure gets provisioned. Observability is the runtime equivalent. Construction ensures things are built right. Telemetry ensures things stay right. Together, they make periodic inspection obsolete.

This is the direction that engineering-led GRC programmes are already heading. The ones that understand how systems work in practice, not through the lens of a control matrix, but through the lens of the actual infrastructure. The signal, not the noise.

Four Skills to Start Building

You do not need to become a data engineer. But you do need to close the gap between where you are and where the data lives. Here is where to start:

1. Learn SQL (or let Claude run it for you). Not to build data pipelines. To ask your own questions of data instead of waiting for someone to build you a dashboard or export a CSV. SQL is the one skill that turns "can someone pull this for me" into "I already have the answer." Every major observability tool supports SQL or a SQL-like query language.

2. Sit with your engineering team for 30 minutes. Ask them to show you Datadog, Grafana, or whatever monitoring tool they use. You will be surprised how much compliance-relevant data is already being captured. Access events. Deployment logs. Configuration changes. Encryption status. All continuously, all structured, all queryable.

3. Think in queries, not questionnaires. When you see a control, ask: "Where does the data live that proves this is working?" not "Who fills out the form that says this is working?" That single question changes how you design evidence collection.

4. Understand your company's tech stack on its own terms. Not through the GRC lens. Not through the audit lens. Understand how your platform team deploys code, how your infrastructure team monitors uptime, how your security team detects anomalies. Understand the actual feedback loops, not the documented ones. That understanding is what makes a GRC professional irreplaceable. The technical foundations newsletter covered this in detail.

The Career Capital Move

The GRC professionals who learn to read observability data will become the translators between compliance requirements and engineering reality. That combination, as I have written about before, is rare and valuable.

The tools will keep getting cheaper. AI will keep closing the gap on code generation. What will not get cheaper is the domain expertise to know which data matters, which questions to ask, and how to translate between what the auditor needs and what the system actually does.

Observability exists because understanding the true state of a software system is hard. Compliance exists because understanding the true state of your control environment is hard. The answer to both is the same: structured, continuous, queryable data that lets you understand any state without predicting the question in advance.

That is the future of this discipline. Compliance as surfaced telemetry. Evidence that generates itself. Control testing that runs continuously. And GRC professionals who understand that the path to better compliance was never a better GRC platform. It was learning to read the infrastructure that was already there.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!