r/grc

we’re still prioritizing cloud vulnerabilities by CVSS and it’s not lining up with actual risk.

we scan across AWS, Azure, and GCP and end up with thousands of “critical” findings. patching by score doesn’t move things much because a lot of those sit on assets that aren’t reachable or don’t matter in practice.

at the same time, lower-severity issues tied to exposed services or shared access paths don’t get prioritized the same way. we’ve had cases where something with a lower score but real exposure only got attention later during audit, which is not great.

we tried adding exposure context like public access and ownership, but keeping that accurate across environments is harder than it sounds and drifts pretty fast.

tools that claim risk-based prioritization still seem to lean heavily on CVSS with some added context, but the outcome doesn’t really change. feels like we’re optimizing for the score instead of actual impact.

for teams that moved away from CVSS-first prioritization, what actually made prioritization consistent in practice?

I worked 3 years in IT sales before starting my bachelors degree in computer engineering (graduating this June). Recently I passed the CompTIA Security+ exam. I'm interested in cybersecurity, specifically within GRC. I'm not looking to go through getting a masters degree so Im wanting your opinion; which certificate should I focus on - CISA or PECB ISO27001 lead auditor?

Hi all - I'm exploring some ideas in the space right now, and I'm interested in learning more about what TPRM actually looks like in practice in a healthcare setting. Is there anyone who has worked for a hospital system/health system or standalone hospital that would be willing to share their experience/perspective?

Recently, we decided to reintroduce a TPRM process within our group (the previous process had been abandoned). We set up a very basic process (pre-assessment + security questionnaire), and this ultra-basic process has become incredibly time-consuming. We're now drowning under an absurd number of TPRMs.
Yet I remain convinced that even without a tool, there must be more optimized methods! I'd love to hear your feedback.

Hey everyone,

I’ve been stuck between law school and cybersecurity for a while now and wanted honest advice from people already working in cyber, especially GRC/compliance/risk type roles.

I graduated with a Criminal Justice degree and Pre-Law minor with a 3.94 GPA and I’m currently studying for the LSAT. Law school was originally the plan, but lately I’ve been questioning whether it’s worth it financially unless I get a really strong scholarship/full ride. The idea of taking on huge debt and spending 3 years out of the workforce honestly worries me.

That’s what started making me look into cybersecurity, mainly the GRC/governance/compliance side rather than hardcore engineering or offensive security.

I live in Colorado Springs, so I’m around a lot of defense/government contractor cyber stuff, and cyber seems attractive because of the growth, flexibility, online options, and what looks like a better ROI overall.

At the same time, I want to be realistic with myself. I’m not from a CS background and I’m not someone who’s been coding since high school. I can learn technical concepts, but I’m naturally more into writing, analysis, policy/legal thinking, communication, research, etc.

So I guess what I’m trying to figure out is:

- Is GRC actually realistic for someone with my background?
- How hard is it REALLY to break into right now?
- Does school prestige matter a lot in cyber hiring?
- Is WGU actually respected for GRC/compliance roles?
- How much do you think AI changes this field over the next 10–20 years?
- And based on what I wrote, does this honestly sound like a field I could realistically succeed in long term?

I’ve been looking at programs like WGU, UCCS, CU Boulder Information Science, and other online/hybrid cyber programs.

Part of me also thinks I might still pursue law school later in life if the opportunity makes sense financially. I keep wondering whether combining cybersecurity + law could actually become valuable in areas like privacy, AI governance, cyber law, investigations, compliance, etc., or if that just sounds good online.

If you were in my position, what path would you take?

Would really appreciate honest advice from people already in the field. And if anyone is open to connecting or sharing guidance privately, I’d appreciate that too.

SSO logs show who logged into ChatGPT once. CASB catches some standalone tools if you’re lucky. But try figuring out when someone pastes a customer dataset into Copilot inside an approved Salesforce instance. From the logs it all looks normal.

we’re ~800 people, mix of google workspace, slack, okta, and leadership wants visibility into AI usage without slowing things down.

problem is SSO/CASB mostly give domain hits or API activity. no insight into prompts, data being pasted, or models triggered inside embedded features. notion ai, teams copilot, gemini in docs all just blend into normal SaaS traffic.

tried browser extensions, but users disable them. network DLP misses typed input. endpoint agents feel heavy for this use case.

how are you getting real visibility here. anything that actually surfaces risky usage without breaking workflows?

F500 cyber guy here (CISSP, not defense though so apologies if I'm late to the party). Been helping a couple buddies who run small defense subs prep for L2 and I can't find a clean answer on this from anyone.

Their people use AI for everything now. Copilot, ChatGPT, some are messing with agents. But the CMMC docs don't really address it. DFARS doesn't mention AI. 800-171 r3 has some adjacent stuff but nothing direct. NIST AI RMF exists but try handing that to a C3PAO and see how that goes.

Are you guys treating sanctioned AI tools as ESPs and doing the full categorization, or just bolting on AUP language and calling it good?

What about the analyst who pastes a CUI spec sheet into ChatGPT to summarize it because they're behind on a deliverable? You can't realistically watch every keyboard.

Has a C3PAO actually asked about AI tool usage in an assessment for any of you, or is it still flying under?

And for the workflows where you do let some AI tool touch CUI, how are you proving it's not training on your data beyond what the EULA says?

Feeling like a lot of folks are just kinda hoping it doesn't come up. Would love to know if I'm wrong about that.

Most SOCs have decent detection and decent remediation. What I've watched break consistently is the handoff between them.

A detection fires. An analyst triages. An action item gets generated. The action item lands in Jira, ServiceNow, or, worst case, a Slack thread. The detection team considers the work done at the moment they hand it off. The remediation owner considers the work started at the moment they pick it up. The gap between those two moments is where SLA breaches accumulate, evidence gets lost, and findings show up in the next audit as "remediation not consistently completed."

I'm now at Process Street working on this category specifically, but the pattern I'm describing predates my move and isn't tool-specific. Calling it out for context so you can weight the recommendation accordingly.

What the failure mode looks like in practice. Detection team marks an alert "remediated" because they routed it to ServiceNow, then six months later an auditor pulls a sample and finds 12% of remediations were never actually performed. Remediation owner gets a ticket without context of why it matters, prioritizes it as routine, original SLA was 24 hours and actual time to close was 18 days. Evidence of remediation (config diff, log entry, screenshot, ticket comment) lives in five different systems, compiling it for audit takes 40 hours per quarter. The same vulnerability class recurs because nobody closes the loop back to detection rules.

The structural insight that keeps coming up. The handoff isn't a ticketing problem, it's a workflow execution problem. Ticketing tools (Jira, ServiceNow) are good at tracking discrete tasks but not at modeling "this can't be marked done until that's signed off with specific evidence at the step." That gating layer is its own category. SOAR platforms (Splunk SOAR, Cortex XSOAR, Tines) handle the automation side but most don't model the human-in-the-loop approvals well for control-type-specific evidence requirements.

What I've watched work, regardless of which tool. The handoff has to be a single workflow with both teams as stakeholders, not two systems passing a ticket. The detection team's "done" condition is the remediation team's "received" event, with the receipt requiring confirmation. The remediation owner can't mark "done" without attaching the specific evidence required by the control type (config, log line, attestation). The auditor's evidence package is generated from the workflow run record, not assembled afterwards.

Tools matter less than this structural choice. We've watched it work in ServiceNow with heavy customization, Jira with workflow plugins, SOAR platforms for the automation half, and dedicated workflow execution platforms (Process Street, Tallyfy, similar) for the procedural half. What hasn't worked is leaving the handoff to "the team will follow the SOP we wrote."

Curious what others are seeing here. Are most cybersecurity orgs still treating detection and remediation as separate systems with manual handoff, or are people consolidating into single workflows? And for the orgs doing single workflows, what's the consolidation pattern that's holding up?

Just finished ISO 27001 certification (EU, ~35 employees) using a large “all-in-one” GRC platform and a well-known auditor. Sharing a quick lesson learned:

We trusted the GRC tool too much.

During the audit we had to adjust evidence (in agreement with the auditor). None of these were critical alone, but together they nearly became a non-conformity:

- Scope template incorrectly included the company name by default.

- Scope lacked clear climate-related references.

- SoA template missed basics (company name, applicability yes/no, proper control descriptions).

- Built-in risk scenarios were far too high-level.

- Risk management policy template lacked risk acceptance criteria.

- Third-party management template didn’t clearly address vendor lock-in prevention.

- Templates were overly formal and outdated (e.g. ISMS councils SMBs don’t have, DVDs as asset examples).

- Cloud integrations (AWS, Microsoft, etc.) were great, but auto-generated scan evidence was hard for auditors to interpret, requiring manual explanations.

Individually manageable. Combined, almost a finding. Also learned that auditors interpret some things differently, after disccusion the above with the grc-platform provider.

Posting this as a heads-up for others that are planning ISO 27001 certification with a GRC platform.

TL;DR:

GRC tools help a lot, but their templates are not “audit-safe by default”. Review scope, SoA, risk models, and auto-generated evidence carefully — don’t follow templates blindly.

we have llm powered agents in prod handling customer queries and starting to see cases where behavior drifts with certain inputs. sometimes it ignores guardrails or gives answers that don’t align with what we expect.

we tried input sanitization and prompt guards, but they break on edge cases and add latency. also added output validation, but responses get rephrased in ways that slip through. did some fine tuning as well, but real user input is a lot messier than anything we trained on.

anyone else running into this. what are you using to catch behavior changes before they impact users?

open to any ideas, thanks!

One thing we’ve noticed while working around third-party/vendor assessments is that the actual process is often the weakest part.

Not necessarily the security analysis itself — the workflow around it.

A lot of environments still rely on:

• spreadsheets that grow out of control
• email chains for evidence collection
• flat questionnaires with no real weighting
• manually written executive summaries
• remediation reports with no prioritisation logic
• inconsistent scoring between different analysts/team members

Over time, a few things consistently improved assessment quality and speed for us:

1. Weighted scoring matters more than long questionnaires A focused 15-question assessment with proper weighting is usually more useful than a generic 80-question checklist.
2. Compliance risk and operational risk should be separated A vendor can be “compliant” on paper while still introducing operational/security concerns.
3. Executive summaries should be generated from findings A lot of analysts waste time rewriting the same risk language repeatedly instead of standardising it.
4. Remediation should be prioritised by exposure impact Most reports overwhelm stakeholders because everything is treated with equal urgency.
5. Lightweight workflows get adopted more consistently Teams are far more likely to actually complete assessments when the process isn’t buried under enterprise-level overhead.

Honestly feels like there’s still a huge tooling gap between:

• enterprise GRC ecosystems
• and completely manual spreadsheet chaos

Curious how others here are handling vendor assessments today:

• internal frameworks?
• spreadsheets?
• dedicated platforms?
• custom tooling/scripts?

Would be interesting to compare workflows because this seems to be a pain point almost everyone solves differently.

I need to get an outside company to conduct a pentest on my companies web application sitting in GSP. I've been going through the documentation (and finding out how much is actually outdated) and I saw in the penetration testing guidelines doc version 4 that a red team assessment is now a requirement. My question is, if my app is in the Google's cloud, do I need to have my entire organization red teamed and penetration tested even if none of the app sits at my site?

Was in a call with an auditor today. We were having an interesting convo about the future of GRC tools & automation. He mentioned something I haven't really heard of before: AI CPAs. They're coming, rapidly. They might even replace some of these tools & processes that auditors use.

Is this true? Have you heard of this AI CPA wave incoming? Should auditors be worried?

Hi everyone,

I transitioned into a cybersecurity GRC role about a month ago because I thought it would be a bit calmer than my previous job while also giving me good long term growth opportunities. So far, I’ve found the work interesting, but I’m still unsure whether this is something I want to do long term.

One thing that surprised me is the work culture. I did not expect everyone to leave early every day or anything like that, but I also did not expect to constantly see people online before I start work and still online after I leave, both on remote and in person days.

Leadership has also mentioned there are no plans to increase headcount in cybersecurity despite taking on more clients and adding AI into workflows. Our dashboards also constantly show that teams are behind on tasks.

Another thing I noticed is that many people stay at this company for a very long time, but promotions do not seem to happen very often.

Is this normal across most companies in cybersecurity/GRC?

In my previous role, we mainly had core hours where everyone needed to be available for meetings, but outside of that people managed their own schedules as long as the work got done. I’m trying to understand whether what I’m seeing now is just this company or more of an industry standard.

If you are learning GRC again. How would you do it and which resources would you use. And which things you would ignore?

Does anyone have an experience working in GRC fully remote. Preferably even in a completely different country as the hiring company? Can it be done while living in south east asia. Where you enjoy the nice weather and cheap food. While working as a contractor for a western company.

Is this even possible with GRC?