r/grc

Something I keep running into is orgs that have a solid GRC platform running, dashboards look great, evidence is auto-collected, frameworks are mapped. And then an auditor starts asking whether the controls actually work and it all kind of falls apart. The tool documented everything but nobody verified anything. That's what I'd call compliance theater and it's more common than people admit, even as platforms get more sophisticated. The way I think about it now is that a GRC tool is infrastructure. It gives you a place to centralise risk, automate evidence collection, map controls across frameworks, report upward. All genuinely useful stuff, and with the current wave of AI and continuous control monitoring being baked into more platforms, that infrastructure is getting genuinely powerful. But a compliance program is the operating model that sits around it. Who owns each control? Who's verifying it's functioning, not just documented? What happens when a control fails? A tool can't answer those questions on its own, and most still can't enforce ownership accountability without a human process behind them. Regulators right now are increasingly focused on outcomes and actual control effectiveness rather than documentation completeness, which is pushing this conversation harder than ever. It forces the question past "we have a platform" into "here's proof it works." The gap shows up most obviously during access reviews. You can have a tool generating the review campaigns automatically, but if business owners are, rubber-stamping everything without actually looking, the tool just made your rubber-stamping faster and more organised. The program is the part where someone is accountable for the quality of those decisions, not just the existence of them. So what does your setup look like - do you feel like your tool and your program are genuinely aligned, or is one carrying the other?

For the past 15 years I’ve been writing software development documentation and would like to pivot into GRC. I’m currently studying cybersecurity and would like some advice on the practicality of making this happen.

Working through an AI risk management classification problem that our existing frameworks weren't built for and genuinely not finding useful guidance.

Standard AI risk management handles AI-assisted tools reasonably well. A tool that suggests code is a processing service with defined inputs and outputs. Agentic AI in software development is a different category. An agent that can read a ticket, pull context from your codebase, write code, generate tests, open a pull request, and respond to review comments is executing a multi-step workflow across multiple systems with minimal human intervention at any step.

The questions this creates don't have clean answers yet. What authorization scope should an agentic AI have and how do you audit what it actually did? What happens when an agent takes a wrong action mid-workflow and who is accountable for the outcome? If an agentic AI modifies production-adjacent code autonomously does that trigger change management controls under SOX or ITGC? How do you version and audit an agent's behavior over time as the underlying models and context evolve?

Traditional AI risk management assumes humans at decision points. Agentic AI in development pipelines can eliminate that. Is anyone building controls specifically for agentic AI workflows or is this still going into the general AI risk bucket by default?

This is a stretch, but has anyone performed a vendor risk assessment for HIPAA Vault and received any evidence from the company? They claim "3rd party reviews" but do have not provided any evidence of compliance. I figured I'd check with this group to see if anyone here has had any luck with obtaining hard evidence from the company. They sent me a copy of Google's SOC2 report, but nothing else, and have now gone silent to any follow up questions.

I’m running a risk meeting tomorrow during which I will be presenting the risk register I’ve worked on. My boss wants me to lead the discussion by going through as many items as we can in the allotted time, and discussing the best ways to address each item.

My background is in technical writing/documentation. I like learning risk management and want to make a career of it. But I’m a little out of my element so I figured I’d as for some advice.

So far I’ve gone through the old risk register, archived/deprioritized the entries that were either outdated or I could map to existing controls, reassessed the risk scores/severity levels, and assigned ownership for each risk.

Context about the company: it is a small office with a warehouse/factory in the back. It’s regulated under PCI and we are trying to get ISO27k as well. It’s a US branch of a larger international organization.

Any tips or advice on how I should approach this meeting is greatly appreciated!

My day job involves securing AI systems at scale and I have spent the last few months pulling apart every AI governance framework on the shelf to see which controls actually survive contact with autonomous agents. ISO 42001 and the NIST AI RMF are useful but neither was written for a system that chains tool calls, spawns subagents, and writes to shared memory. They treat identity as a noun, authority as something granted once, and audit as a log of human actions. None of those assumptions hold for agents.

In my opinion, there are three shifts that matter most:

1. Delegation chain as the audit primitive. The question an auditor will ask is not "did the agent have the credential" but "who authorized this agent to act in this context and was the action within the scope." Every agent action has to be walkable back to a named human authorizer with a signed scope. Most programs cannot do this today.
2. Scope enforced at the gateway, not inside the agent. The agent never holds a credential that outlives the call. The gateway enforces scope, mints call-scoped tokens, and refuses calls outside scope. Agents cannot be trusted to stay inside the lines especially under adversarial prompts.
3. Memory as a provenance problem, not a storage problem. Memory poisoning is the attack that waits. The defense is to tag every piece of content in an agent context with the identity and authorization of whoever wrote it, and to treat memory reads as untrusted input.

I am interested in knowing your opinion on which of these controls are the hardest to implement and evidence for. Also, what are some other AI Governance controls that are truly effective for AI agents instead of just acting as compliance theatre?

NOT career advice- current practitioner advice being sought.

Context - Cyber analyst team of 3(2CISSPs, with different skill sets, eg app dev, Cisco certs, cyberark etc.)- current responsibility - Infra control review and setup for on-prem FW and WAFs, EDR, vulnerability mgmt ( risk approach)

Industry relevant framework CTPAT, NIST CSF and insurance requirements. No PCI.

Cyber Manager/director left - open role for 3 months, still interviewing. We report directly to the VP of IT who asked us to build out the GRC function. Other security function are about 2/5 CMMI.

I am the one that took the opportunity as I've been pitching a risk based approachfor Vuln Mgmt. I am also looking for roles outside of this org and saw it as good career development.

After some research I presented the VP with a 12-18 month approach in 4 phases. I am currently in phase 1. Unfortunately he is not someone I can lean on for guidance and without a direct manager I'm doing this on my own. Would you practitioners be able to give me some guidance?

Phase 1 0-60 days

Risk register currency update - started
Did a presentation on why GRC for all of IT - done
GRC charter draft - done
Asset criticality - done
App criticality - not started
Policy gap analysis -done

Does this look like a good place to start? We will likely not be going with a tool but remaining in the world of spreadsheet in the near term at least.

In many compliance audits, trade license verification doesn’t always receive the same level of scrutiny as financial controls, data protection measures, or broader governance checks, but there’s an argument that it should be treated with equal importance. When vendors, suppliers, or business partners are operating with expired, suspended, or even invalid trade licenses, the organization can be exposed to legal, operational, and reputational risks that often go unnoticed until an issue arises. What’s interestinG is that this area sometimes gets treated as a one-time onboarding requirement rather than an ongoing compliance obligation. Once a vendor is approved, continuous monitoring of their licensing status can easily fall through the cracks, especially in large organizations managing complex or cross-border supplier networks. I’m curious how others are handling this. Are compliance or procurement teams actively strengthening ongoing license verification processes, or does this still remain a somewhat overlooked gap in most workflows and audits today?

Been sitting on this for a while after going through a few tool evaluations recently. Every vendor demo follows the same script. Continuous monitoring, automated evidence collection, audit-ready dashboards, risk scoring out of the box. Sounds great. Then you actually implement it and spend the first few months doing manual mapping, fixing integration gaps, and rewriting templated policies that don't reflect how your org actually operates. What gets me is the pitch is almost always framed around efficiency, cost savings, faster audits. And look, those things matter. But there's still a gap between that and whether your compliance program is actually reducing risk in any meaningful way. The industry conversation has started shifting toward business outcomes, tying GRC success to real risk indicators and not just audit, closure speed, but I'm not seeing that translate into how these tools are actually sold or implemented on the ground. I've seen orgs hit SOC 2 with a shiny unified platform and still have no real visibility into their access risk or control failures. Checked the box, got the cert, program's still pretty fragile underneath. The tooling looks mature. The fundamentals aren't there. And that's the thing. These platforms are facilitators, not a fix. The continuous monitoring and automated evidence collection are real capabilities, but they only move, the needle if the underlying control design and policy structure are solid to begin with. Most of the implementation pain I've seen comes from orgs buying the software before they've figured out what they're actually trying to govern. Curious if others are running into this. Is the disconnect the tool, the implementation approach, or is it that orgs are still treating GRC as a certification exercise rather than an actual risk program?

I mean things like subprocessor list updates, processing location changes, DPA / trust page updates, or new AI disclosures from vendors.

How you ensure that vendors of your vendors are compliant? Is this a thing or nobody thinks about 2-level vendor compliance

Do you mostly rely on vendor notices, periodic review, or some other workflow?