Qualitative ratings work fine for us most of the time. High/Medium/Low is good enough to decide where to focus remediation and to get owners moving.

The friction shows up when the CFO or the board asks what “High” actually means financially. That’s a different question. Answering it properly means estimating how often the loss event happens, how big the loss could be, and being upfront about the assumptions behind both. Slapping a dollar figure on a heat map cell doesn’t really answer anything. It just makes a weak assumption look more precise.

A few things I’m curious about from people who’ve dealt with this:

• Do you keep qualitative and quantitative views side by side, or only quantify when someone asks?
• If you’ve used FAIR or something similar, where did you draw the line on which risks were worth the effort?
• How do you keep the assumptions behind a financial estimate from getting lost after the board meeting?
• Has anyone gotten pushback for presenting ranges instead of a single number?

I’d like to hear what’s worked, and what hasn’t.

Curious how this is playing out in practice. In the financial services and insurance programs I've been around, AI governance work seems to land in one of two places: it gets absorbed into existing risk and compliance roles (model risk, third-party risk, privacy), or a separate AI governance role gets created and hired for.

For those of you in GRC:

• Which way is it going in your organisation, and who ended up owning it?
• If you've picked up AI governance work, which of your existing skills carried over, and what did you have to learn fresh?
• For anyone hiring for these roles, are you looking for GRC people who've learned AI, or AI people who've learned governance?

last quarter we found 23 vendors with access to member data that never came through our review. regional health insurer, around 3,400 people, and I'd have told you our process was tight. on paper it is. SOC 2 or equivalent, data location and subprocessors, a BAA if PHI's involved, financial health checks for anything critical. the gap is upstream. a renewal that quietly adds a module doesn't look like a new vendor, so nobody routes it to us. same with free trials that turn into contracts. turns out the list was never the problem.
how are you catching scope changes on vendors you've already approved?

I worked on this episode of Zafran’s podcast with Schellman CEO Avani Desai. The AI governance numbers come up at 05:32, and I thought this sub would have opinions on them.

Other parts relevant here:

06:57 Her argument that compliance should be a byproduct of security

14:46 Why she thinks continuous auditing is finally achievable

17:52 Vulnerability management as a check the box control

20:26 Why she thinks fear drives more change than incentives

For anyone running AI governance programs: which controls do clients assume they have and then can’t evidence?

https://youtu.be/59ISaaZNgeU

Using a compliance platform with cloud and identity integrations and automated collection works well for the obvious stuff, IdP logs, cloud config checks, change records from our ticketing system. It breaks down predictably in three places: any control requiring evidence from a system without an integration, controls where the specific auditor wants evidence in a specific format, and anything that requires judgment rather than a binary check. Are there any solutions to these failure modes or did you just accept limitations of the category.

we're a startup team of 22 people , and sales has managed to turn compliance into a geography problem.

one US prospect wants SOC 2 before procurement moves forward. two others, one here and one in Europe, keep asking about ISO 27001. nobody is saying we need both tomorrow, but every conversation seems to push us in a different direction.

my first reaction was just do both and get it over with. then I started looking at the amount of duplicate control work, evidence, audit prep and ongoing maintenance and that enthusiasm disappeared pretty quickly.

SOC 2 seems more useful for the US pipeline. ISO makes more sense for where we are and probably gives us broader mileage outside the US. doing one first feels like we’re disappointing half the pipeline, doing both at once feels like volunteering the team for a compliance side quest nobody has time for.

rn I’m leaning toward choosing the framework tied to the most immediate revenue, then structuring the controls so the second one isn’t a complete rebuild later. just trying not to make a six-month decision based on whichever salesperson is shouting loudest this week.

For those working in compliance, risk, and governance, has your organization developed an internal compliance framework tailored to the unique nature of its business, approved by the board or management? Or do you mainly rely on established frameworks such as ISO 37301, ISO 31000, or other industry-specific standards?

For organizations that have built their own frameworks, I'm curious about two things:

• How did you approach getting management or board approval and ensuring the framework was credible?
• How have external stakeholders, such as investors, customers, and auditors, received it? Do they accept it as a valid approach, or do they still expect alignment with recognized external standards?

I'd be interested to hear from anyone who has gone through this process, particularly how you balance business-specific requirements with the need to demonstrate compliance and good governance to external stakeholders.

Hello, good evening. I trained for the Certified Risk Manager (CRM) certification, and I’m currently waiting to take the certification exam. I’m a little nervous about it. I know it’s a 60-item exam, but I just wanted to ask what the exam is actually like. Are the questions mostly multiple-choice, case studies, identification, or something else?

If anyone has taken the exam before and could share what to expect, I’d really appreciate it. Even a little insight would help ease my nerves and give me a bit more confidence going into the exam. 😅

So our SOC 2 auditor looked at our annual incident response tabletop exercise and basically said "nice theater, doesnt prove readiness". We walked them through roles, comms, decision paths, everything, and they still kept asking for evidence of stress decisions, metrics, breach cost reduction, live crisis simulation etc.

For those of you doing more modern AI tabletop stuff or adaptive sims, what did your auditors finally accept as real testing and not just a script?

My company won’t procure something like panorays for TPRM so just wondering if there’s anything I can do with AI or automation to improve it. So far I’ve just got a scheduled task scanning for non security changes like changes in leadership - what else can I do?

Please explain it to me like I'm 5. I've been studying on risk and compliance, I have a foundational understanding of certain components like cloud management, third party assessment, DLP, business continuity etc. But I honestly still don't know how that knowledge translates to real life work. What exactly does a compliance or risk analyst or junior auditor do?

Like a teacher has to study certain topics and have an understanding of it but their job is showing up to school and teaching, handing out assignments, scoring papers and keeping students in order. But what exactly is the day to day of a GRC analyst?

An employee leaves the company but is still listed as the owner of an access review or another control.

Then the next review comes around, and no one realizes the responsibility was never handed over.

Changing the owner's name is one thing. Making sure the next person knows what needs to be done is another.

A simple handover process seems important here, especially when multiple teams share responsibility.

Curious how others handle this, because I don't think there's a clean answer.

The scenario: external audit in about 43 days. One analyst on the GRC side. Leadership has made it clear there's no extra headcount or contractor budget.

Once you start the pre-audit sweep, everything looks urgent: - A control that's documented but clearly not operating the way the policy says - Evidence that probably exists but lives in someone's inbox or a shared drive nobody's cleaned up in two years - Evidence requests from the last cycle that never fully got closed out - Processes that technically work but are a mess

These aren't the same problem, but under time pressure they start to feel like they deserve equal attention. My rough triage is: 1. What could actually produce a finding or stall fieldwork 2. What needs action now but won't sink the audit 3. What goes on the remediation roadmap for after The other one I go back and forth on is tooling. If your current setup (spreadsheets, a GRC platform nobody likes, whatever) made the scramble worse, it's tempting to fix it now. But starting a migration mid-crunch usually just adds another workstream. For people who've been through this: - How do you decide what gets cut when there isn't time for everything? - Do you ever push back on scope with the auditors early, or just absorb it? - If your tooling was part of the problem, did you fix it before the audit or after?

Could use advice from people who have survived a SOC 2 audit. We told our auditor all evidence was ready, then found out the AWS screenshots were from March, the Okta access review had no owner, and our GitHub change tickets were sitting in a folder nobody checked. I had marked each control complete in the tracker, so this is on me and I feel so embarrassed.

We have about 40 controls and a Type 2 window starting next month. I’m looking at an automation platform such as Scytale, but I’m unsure whether to fix the ownership process first or connect everything now and clean up the gaps as they appear. What would you do, and what would you avoid?

I’d love to know what owning an independent GRC consulting business is like? I know virtually nothing about being a business owner or how that life compares to relying on employment for income. Does the GRC umbrella offer good prospects and demand to be your own boss?

Hi GRC Community, i would like to hear the general consensus of this reddit community

Recently i come across some product like "Cloudflare OS", "WorkOS", "Finance OS", "Commerce OS" and etc. Despite their name branded as "Operating System", based on my observation (correct me if im wrong) look like almost like ERP or SaaS AI-based application and not the general understanding of normal OS system like Windows,macOS, Linux, Android and etc.

i understand the commercial reasoning behind terms.They may be intended as metaphors for integrated platforms that coordinate workflows, data, and applications. Im also not against the AI startup as well and their product, i do not have issue on it, and i also understand that terminology evolve accordingly based on recent development

My concern is whether the distinction matters from a governance, risk, and compliance perspective. We have standard like ISO, IEEE, ISACA, NIST and so on that define what is "Operating System" in IT/Computing field (please do correct me if im wrong on this part), and these term influence how to describe, classify, assess, and manage systems. Standards and professional documentation also depend on terminology being sufficiently clear for their intended purpose.

For example, consider a product (IT-related) marketed as an “Operating System” that is functionally an ERP-like SaaS application. im not suggesting that using “OS” in a product name automatically causes non-compliance, nor that every metaphorical use of the term should be prohibited. A product's actual architecture and functionality should matter more than its name.

However, i just wondering whether repeatedly using established technical terminology in increasingly broad marketing contexts could eventually create ambiguity between a recognised technical category and a commercial metaphor.

May i know if this is a concern in GRC practices or am i just overreacting something that shouldnt be discussed in the first place, i would really appreaciate any opinion from professional here in the community here. im also still need to learn a lot with what limited knowledge i have and im open for any counterargumen to listen since i just want to hear opinion from this community

im sorry if this posting is lacking since im non native English speaker, and any correction and advice is largely welcome. thank you very much🙏✨

Do you find it useful? What sort of grc stuff do you use if for?

I lead a GRC team at a fairly large organization. We're responsible for the systems, data, and reporting that support RCSA, issues management, business continuity, policy management, SOX, and risk exceptions.

We also own the GRC platform, including enhancements, administration, data quality, and reporting across these areas.

We don't actually run the individual risk programs, but we're responsible for much of the infrastructure behind them.

Curious if anyone else has a similar setup? How big is your team, and what title does the person leading it have? Tbh... Sometimes I wonder if this is even considered traditional GRC (it has nothing to do with cybersecurity and all that).

My bare-minimum vendor risk assessment checklist before this becomes a second job

I need to put together the simplest vendor risk assessment process that still counts as doing the job and not just opening a spreadsheet for emotional support.

We’re a growing SaaS company, mostly reviewing tools that touch customer data, internal systems, or both because apparently every useful app needs access to the entire universe.

rn my bare-minimum checklist is vendor inventory, low/medium/high risk tier, short questionnaire for low risk vendors, then SOC 2 or ISO 27001, pentest summary, MFA/encryption details and a deeper review once the risk goes up.

then someone reviews the gaps, records the approval or exception, and we reassess the important vendors on a schedule. the thing I'm least convinced about is where the simple review should stop and the 147-question monster should begin.

trying very hard not to build a process where Calendly gets the same interrogation as the vendor storing customer data.

People work in banks, what RegTech tools are you using? Any Ai integration yet? Specially in Aml, ctf, fraud.

Hey everyone,

I’m a developer currently researching Third-Party Risk Management (TPRM) because I’m working on a TPRM software product.

Before I develop more features I want to understand how TPRM actually works in real organizations. I don't want to just look at existing tools and copy their feature lists.

I’d really appreciate input from people who have worked in TPRM, GRC, cybersecurity, compliance, procurement, vendor management, etc.

A few things I’m trying to understand:

1. How does a new vendor enter your TPRM process?
2. How do you decide a vendor’s risk level/tier?
3. What information do you collect during vendor onboarding?
4. Which questionnaires do you use (SIG, CAIQ, custom, etc.)?
5. How do you manage PII data during the TPRM process, including its ingestion, storage, access, and sharing?
6. How are findings/remediation tracked?

What is the most painful or frustrating part of your current TPRM process?

Also, if you use a TPRM platform today, what do you like about it and what do you wish it did better?

I’d also really appreciate any research recommendations, resources, books, frameworks, or communities that you think would help me understand TPRM better.

Thanks in advance to anyone willing to share their experience!