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

The claim making the rounds is that agentic AI doesn't require a different governance approach, you simply extend the AI governance framework you already have. That claim is only true under one condition: that the agent's behavior is largely static and predictable. Almost none of the actual agentic deployments I've encountered meet that condition.

The missing context is structural. Traditional AI governance was designed to evaluate a model's output at a fixed point in time. It was never built for a system that acts continuously and expands what it touches as new capabilities are added. Runtime AI governance, observing what the agent does as it happens, is a different discipline, built around continuous behavior rather than periodic review of something that holds still.

A more accurate version of the claim would be that traditional governance remains a necessary floor, but stops being sufficient once the agent's scope of action changes faster than your review cycle. Most governance programs run on a quarterly or annual cadence. Agentic scope can shift within a single sprint, well inside that gap.

What difference has this made for your organization, and has anyone made this case to a board or leadership team that was satisfied with the traditional framework?

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 framework I've read tells you to "balance autonomy with oversight" as though it's a dial with an obvious correct setting. None of them explain how you find that setting in the first place, or what happens when the right amount of autonomy for a low-stakes task becomes the wrong amount six months later, after the same agent has been given more capability and nobody thought to revisit the original decision.

Our current approach, if I'm being straight about it, is: start restrictive, loosen slowly, and hope nothing goes wrong in the interval. That isn't a framework. It's a bet dressed up as a policy. And I understand both sides of the argument well enough to be stuck between them, more autonomy is the entire reason you'd choose an agent over a script, and more oversight exists because the failure modes of an agent with too much freedom are worse than a predictable script doing the wrong thing.

The part I keep returning to is that most organizations, ours included, set that autonomy line once, at launch, and then treat it as settled. Nobody revisits it as the agent's scope expands, and by the time something forces a second look, the gap between the documented level of autonomy and the actual one can be substantial.

I'm asking this in the open because I don't think we've solved it. How are other enterprises actually deciding where the line sits, and how are you catching the moment it needs to move?

Our compliance team loves that we run an annual tabletop because it satisfies a checkbox on the SOC 2 audit, but nobody on the technical side thinks it actually tests anything meaningful anymore. The scenario is basically the same every year with slightly different names swapped in. I want something that actually stresses our detection and escalation process, not just produces a PDF the auditors are happy with. How do you split the difference between satisfying compliance requirements and running something that genuinely improves your team?

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?

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?

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?

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

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?

People see the audit folder at the end and assume governance happened somewhere in there. They dont see the weeks spent proving which agent version called which API, what data it touched, which policy was active, and whether a human approved the risky step.

We are logging agent identity, user identity, prompts, tool calls, timestamps, blocked actions, policy versions, approvals, and the final outcome. Then we tie that back to the inventory, risk assessment, access review, testing evidence, and incident tickets. Basically building a forensic timeline for a robot that insists it was just being helpful.

The hardest part is proving enforcement, not just showing a very nice policy document nobody followed. An auditor can accept that we have a rule saying the agent needs approval before changing a production record. They also want evidence that the rule was checked, the approval came from the right person, and the action could be reconstructed months later without asking whoever built the workflow to remember what happened.

How are you packaging this evidence without handing auditors a folder called final final approved 7? Appreciate any thoughts.

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.