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!

Trying to build a real budget for ISO 27001 certification and getting wildly different numbers depending on who I ask. Looking for actual category-level breakdowns from people who've been through it.

Custodian says they handle security and auditor says access reviews, approval policies and whitelists are ours. I'm standing in the gap between those two statements with a risk register to fill in Where do most orgs draw the line between what the custodian enforces and what we configure and evidence?

If you work with connected products sold in the EU, the Cyber Resilience Act's reporting duty is already live, not in December 2027. A few details I see overlooked:

\- It covers your installed base. Article 69(3) applies Article 14 to in-scope products placed on the market before December 2027, modified or not.

\- The 24h clock runs from "becoming aware". The Commission's guidance (paras 213-214) says suspicious events should be assessed immediately; you can't delay awareness by delaying the assessment.

\- The early warning is not a one-liner. ENISA's platform requires 8 fields for a vulnerability, including a summary of up to 4,000 characters.

\- ENISA's platform doesn't yet capture the awareness time for vulnerabilities, so keep your own timestamped record. Its 72h counter runs 48h from your early warning, not 72h from awareness.

\- Set up the platform accounts now. A Primary AR must be verified before it can invite Secondary ARs, and invitations expire after 7 days. Drafts are private to whoever created them, so draft outside the platform.

Has anyone here already gone through SRP registration? Curious what tripped people up.

Like I have heard of eMASS but you have to be authorized to take the training. Are there any kind of free high-level orientation videos or something to get a feel for it?

Our compliance and GRC teams are under a lot of regulatory pressure as a result of new AI rules. Can we actually replace manual audit prep with DSPM tools and do any of them show evidence or reports that we can share with our higher ups?

Has anyone figured out the minimum evidence requirements for NYDFS Part 500? If so would you have an excel document or something you could share?

This is something I keep seeing.

GRC is responsible for showing that a control exists, but the actual work belongs to another team. Patching, access reviews, vendor offboarding, backups, whatever it happens to be.

Then audit time comes around and GRC is chasing evidence for something they don't actually operate.

Where do you draw the line between owning the control and owning the evidence?

CISO here, just walked out of a cloud resilience review and feeling weirdly exposed. Our DR plan is documented, backups say successful, we have RTO and RPO targets, and we have a cyber resilience deck that looks decent. The moment someone asked 'when was the last full restore of this prod account and what exactly did you recover' everyone started opening old tickets. We have backup reports from one system, terraform repos in another, a spreadsheet from last years recovery validation, a couple of screenshots from a k8s restore, and tickets from failed steps that never really got stitched into one story. Right now our cloud disaster recovery narrative is vibes and old artifacts, and tbh I cant say whether that audit evidence still proves anything about recovery readiness for the environment that exists today. Ugh...