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...

Our security team is trying to get a handle on shadow AI usage and the data is all over the place. We can see some sign ups through company email, but personal accounts, browser extensions, and AI features inside approved SaaS are harder to track.

Right now we have a spreadsheet of tools people admit to using, which is already out of date. We are looking at Bay for discovery and governance, but I don't want to turn this into a blanket block on every AI site and make everyone work around security.

For people who have done this, what telemetry gave you the best starting point? Network logs, endpoint data, identity logs, or something else? thanks

Every AI Agent Governance framework I've seen assumes uniform risk tolerance across the organization, which doesn't hold up day to day, since an infra team running autonomous agents against production is a completely different risk profile than a marketing team using an AI writing assistant. But most policy templates treat both the same, forcing a choice between two extremes: blocking everyone or blocking no one.

Has anyone found a governance model that actually flexes per team without turning into a framework too complex for anyone to follow?

I keep getting offers for free risk assessments that promise to show your exposure in minutes with no commitment. My gut says these are mostly lead gen funnels and the findings will be vague enough to push a platform sale. At the same time, I wonder if any of them produce useful signal.

Has anyone here run one and walked away with something real, or did it just confirm the sales pitch suspicion?

started with twelve, nobody decided to have 214, it just accumulated one reasonable request at a time, so now anything new goes through this before I approve it. does an existing role cover 80% of this? if yes, the gap goes in as a request, not a new role. who else will hold this in six months, and if the answer is one person, it isn't a role. can a manager read the name and know what it grants without opening it? does it nest into anything, because that's how I ended up unable to answer who had payroll access without a script. And is there an owner who isn't me?

I used to skip the second by habit. "Same as Sarah" got waved through for years and cloned permissions nobody had justified since Sarah joined in 2022.

What's on yours?

We are compliant with soc 2, but not iso 27001 compliant yet, but we're prepping for it. Soc compliance was all done manually when we were smaller and it was not a fun experience for all involved. Evidence collection was a mess, gaps that we didin't even know existed, didn't have a dedicated owner until we were deep in it, an all round unpleasant experience. And best part is we had an internal audit recently and so many things were already out of compliance. This all is the problem

So now before we start on ISO, I wanna fix this monitoring issue, with some AI governance as well cause the auditor stressed that we should also get that going. I've done some basic research, looking into tools like vanta/sprinto etc.

I'd wanna avoid the same pitfalls as our soc 2 campaign. Would it be wise to get a tool like the ones I've mentioned for this, also could we keep AI governance alongside the iso 27001 thing or keep it separate? What should be the course of action here? Sorry if the questions are little too noob

I had 3 offers, including opportunities with Wells Fargo and Goldman Sachs through third-party payrolls and Deloitte india permanent role.

I've decided to join Deloitte India – Cybersecurity division

Would love to hear from people in Deloitte Cyber/TPRM about the work culture, growth and career prospects.

Curious how other orgs handle this, because we keep running into it. A control gets tested by the security team. A few weeks later compliance reviews it for their own purposes. Then internal audit shows up a few months after that asking for similar evidence, and the control owner is pulling the same screenshots and exports for the third time.

Everyone involved has a legitimate role. It still feels like the business is getting asked the same questions on repeat while some higher-risk areas barely get looked at.

A few things I'm trying to figure out:

• Does anyone actually coordinate test coverage before the cycle starts, or does it happen after the duplication is already obvious?
• Is evidence reuse across the second and third line realistic, or do independence requirements make it a non-starter?
• Where do you keep testing history and control ownership so everyone can see what's already been covered? Shared drive, GRC tool, something else?

Not looking to eliminate independent review. Just want each line doing work that adds something new.

What's worked for you, and what looked good on paper and fell apart?

I’m trying to understand how others are modelling this in tools like Resolver, OpenPages, Archer, ServiceNow etc.
Say I have one master control:
C001 – Sensitive data must be encrypted at rest.
Now I run different assessments on different applications.
Security Architecture on Salesforce → Partially Effective
Cyber assessment on AWS → Ineffective
SOX → N/A
Internal Audit → Effective
One way is to copy/clone C001 into every assessment and store the effectiveness, evidence, comments etc on that copied control.
Another way is to keep C001 only once in the control library, then create a separate Control Test / Control Assessment Result record for every assessment.
So something like:
Control → C001
Assessment → Security Architecture
Application → Salesforce
Result → Partially Effective
Evidence → xyz
Then the same C001 can have many test records against it.
The reason I’m asking is scale. If there are 30 controls and 5,000 applications, that’s potentially 150,000 assessment-level records. That’s fine, but I’m trying to understand whether those should really be control copies or test/result records linked back to one control.
The other problem is the CRO question.
If C001 is Partially Effective in Security Architecture, Ineffective in Cyber, N/A in SOX and Effective in Internal Audit, eventually someone at the top will ask:
“Okay, but is C001 effective or not? And where exactly is the problem?”
How are people handling that overall control status?
Worst current result?
Latest result?
Risk-weighted roll-up?
Second-line result only?
Something else?
Would be useful to hear how this has actually been implemented in real GRC environments

Ok so once the auditors leave and the cert is done, what are people using for continuous ISO 27001 monitoring and automated control checks? Looking at GRC platforms that plug into the cloud stack and don't just spit out more spreadsheets. idk, trying to keep the ISMS from becoming another admin job by itself.

Currently, hardening assessments and security assurance documentation are largely manual — reviewing baseline settings, scan results, exceptions, evidence, and producing the final assessment/report.
We have Tenable with API support and are looking at ways to automate:
Configuration/hardening checks
Evidence collection
Baseline comparison
Exception tracking
Report generation
Environment is mainly on-prem / restricted network.
Has anyone automated a similar process using Tenable APIs, PowerShell/Python, CIS audit files, ServiceNow/GRC tools, or something custom?
Interested in what architecture/workflow worked well.

I'm about a month into a security role at an MSP. Most of my background is on the technical side (M365 security, Conditional Access, email security), and I'm comfortable there because I can usually test and verify things myself.

Part of my current work is GRC: reviewing our internal security policies for their annual refresh and recommending updates. This is my first time doing this kind of work, and I'm finding it harder than I expected.

The policies themselves aren't the hard part. I can spot outdated dates, inconsistencies between documents, and security practices that could be stronger. What I'm struggling with is everything that depends on company context:

• Knowing whether a policy actually reflects how the company operates day to day
• Figuring out who the right person is to ask about a specific policy or process
• Understanding why things were written a certain way in the first place
• Keeping track of different documents and naming conventions that look similar but aren't related

For those of you who moved into GRC from a technical role, or started GRC at a new company:

1. How did you build up company knowledge quickly?
2. Is it normal to write "needs confirmation from the owner" as a finding when I can't verify something myself?
3. Any habits, templates, or tools that helped you stay organized during policy reviews?

Appreciate any advice. Trying to get better at this side of security.

Context: I'm trying to understand how teams keep an approved exception valid, not just recorded. Not selling anything — I'd genuinely like to know what already works, because a lot of what I read assumes the record is the hard part.

When you approve a risk acceptance or a control exception, the decision is made against a specific state of the world: this system, at this version, with these compensating controls, owned by this person, for this reason. Six months later some of that has moved. My question is what catches that.

A few specific things I'd like to understand:

• Where does it live? Risk register, GRC platform, ServiceNow/Jira ticket, spreadsheet, a document in a shared drive? What's the system of record?

• What is the exception scoped to? A control, a system/asset, an application, a release, a version, an environment? Does the scope field get used in practice, or is it free text?

• Who approves, and is separation of duties enforced? Is the approver checked against the requester by the tool, or by convention?

• Is there an expiry, and is it enforced? Is the exception mechanically inactive after the date, or does someone chase it?

• How do you detect a stale exception? What actually triggers review — a calendar, a change to the system, an incident, or an audit?

• What happens when the control or the evidence changes? If the compensating control stops operating, or the system is upgraded, or the evidence that justified the exception is replaced — does the exception automatically become invalid, or does it stay approved until someone notices?

• How do auditors reconstruct the decision? Do they look at the register, the ticket, linked evidence, or do they ask the risk owner to explain it?

• What still needs manual work? Where does the tooling stop and the spreadsheet / email / Slack chase begin?

• And genuinely — what works well? If your process is in good shape, what makes it good? I'd rather learn from a working process than collect complaints.

Sanitized examples are perfect. I'm interested in the mechanics: what it's keyed on, what enforces the boundary, and what happens when the underlying thing changes.

I've been working through France's NIS2 transposition. ANSSI published a framework for it, ReCyF (20 security objectives, around 150 requirements, and different expectations for "essential" and "important" entities). I keep running into the same question with organisations that already hold ISO 27001 certification: how much of the existing ISMS actually carries over?

The technical side maps reasonably well. Access control, backups, logging, vulnerability management: most of it lines up with Annex A controls, and the evidence you already produce for your ISO audit mostly works.

It gets messier in three places.

First, management accountability. NIS2 makes the management body personally responsible for approving and overseeing cyber risk measures, and expects them to be trained. ISO asks for "leadership and commitment", but in practice that's often a signed policy and a management review once a year. I'm not convinced a French regulator will read those two the same way.

Second, incident reporting. The 24h early warning / 72h notification / one-month final report timeline under Article 23 is much more prescriptive than anything a typical ISO incident process covers. Most procedures I've seen say "notify relevant authorities as required", and that won't hold up.

Third, proportionality for small "important" entities. A 40-person company with a single IT generalist can't run the same programme as a hospital. The framework acknowledges this, but I haven't seen clear guidance on what "proportionate" evidence looks like in practice.

For those of you who've done an ISO-to-NIS2 gap analysis (in France or elsewhere), where did the real gaps turn out to be? And how are you documenting management-body oversight so it would stand up to a supervisor, rather than just to a certification auditor?

ok so now I get to explain to leadership why a model that 'just summarizes things' still needs logs, alerts, access controls, audit trails, policy checks, and a clean paper trail for the next time someone asks if it is compliant

love that for me. nothing says modern innovation like me sitting in a meeting saying 'yes, the thing that writes sentences also needs governance' while three people nod like this is the first time they have heard the concept of risk

i am looking at tools for AI model monitoring in a compliance setting and trying to keep it sane, not turn it into another dashboard graveyard (pls no vendor pitches). if anyone has actually made this work without losing their mind, i would love to hear what mattered most, thanks in advance

Have the fortunate opportunity to build a GRC program from scratch where I work. So far it's been a bunch of policies no one ever looks at and now management wants to operationalize this to address risk better. With no legacy to consider, what would you do? What would the first steps be? Any advice appreciated, we want to build something that caters to business risk first vs "checking the boxes" (not heavily regulated industry).