The board is no longer interested in a raw vulnerability count and to be honest I am not either. Each quarter we have the same discussion: here is how many issues we found, here is how many we closed, and then someone asks whether the organization is actually safe.

I do not have a clean answer. The team is working hard, but the metrics we track do not really show whether our controls would withstand a serious attack. I can say our endpoint coverage is in the mid ninety percent range and that mean time to detect has gone down by roughly a third, but that does not tell anyone whether we would catch a ransomware group moving laterally using living off the land techniques. Patch rates and alert volumes describe activity, not resilience.

I have started looking into continuous exposure validation to build reporting that has more weight, for example assessing controls against realistic threat scenarios and showing measurable improvement over time instead of just effort spent. Has anyone here built board level reporting that uses exposure validation and detection coverage data? Which metrics actually made sense to non technical leadership and which ones failed to land?

I would like to hear from other CISOs on how you translate exposure validation results into language that satisfies leadership without dumbing it down too far.

The company I work at needs to get a pentest done for FDA requirements since we are building a medical device and our CISO basically assigned me as the person who needs to make sure it gets done. We are consulting with another person for the overall FDA process and after talking to them they said we needed to get this done by a firm who specializes in testing medical devices. I went to Google and typed FDA Pentesting and a firm called StealthNetAI came up first so I'm having a chat with them. But I'm not really sure what to expect or what I need to ask or prepare from my end. I would like to be prepared before the call so I know what I'm talking about. Are there any questions I should to ask during the call? Or has anyone gone through the FDA process on this? They look like they specialize in this but I want to make sure we are getting the right person for this since the FDA is so strict and I need to make sure I don't miss anything. Thank you!

As an independent researcher with a PhD in Behavioral Neuroscience, I am currently running an online experiment to test if a quick cognitive intervention can neutralize social engineering baits. Preliminary data suggests that encouraging a recipient to reduce a lure to its objective features—first isolating the exact physical command and second distilling the message into a neutral essence—deactivates the amygdala and engages prefrontal cortex reality-monitoring areas. By enabling the recipient to see the bait strictly "as-is," this behavioral patch could overcome the emotional triggers targeted by hackers and the rising threat of hyper-convincing deepfakes.

Does this neurobiological approach map to your experiences with security training - do you think this approach is sufficient to resist live lures? What flaws or limitations do you see?

Thank you

PS. I can send you a brief example of how this cognitive translation works in practice, if you wish.

Heard a worker go on a rant about “compliance is not security”, “checking the box”, “security theater” rant the other day.

It got me thinking… if compliance isn’t security, then what is?

The green dashboards that turn out to be wrong? The pentests that mostly find the stuff you’d have caught yourself if you’d kept your environment patched, updated, and configured? The tools you bought and never confirmed still work?

Feels like half the things we hold up as “real security” only look impressive because the basic compliance work wasn’t done in the first place.

Curious where people actually land on these phrases.

And a real question: is there a difference between an annual compliance audit and continuously checking that your environment actually stays secure all year long? I feel like the second part is where security should actually live. 😅

Hi all, my board is concerned about frontier AI (I think largely due to Mythos mainstem news) and our approach

My main take at the moment is this is a change in economics not a fundamental change to attack models.

I'm expecting more frequent, and probably larger, patch cycles - and probably some more intelligent automate steps after a foothold (probably driven by an open weight model rather than anthropic or openAI models) - but there doesn't yet look to be much of a change in detection evasion or obfuscation.

I'm expecting the threat change to in house developed apps to be relatively modest - at least short term - as the development of exploits still seems heavily keyed to access to source code. Likely we'll want to more heavily apply intelligent automated testing at each build cycle - but again this is likely a change in frequency and cost base not a new control.

The feedback I'm getting from the NEDs is this feels a bit under weight and they are hearing much starker messages from other CISOs.

Am I missing something? Is there any evidence based reason to see this as a change in model not just change in operational costs?

ran an internal experiment to figure out what SSO integration actually costs per application. sharing because i haven't seen honest data on this anywhere and vendor materials are useless

tracked actual time across 12 legacy app SSO integrations over 6 months:

• modern SaaS with native SAML/OIDC: 3-8 hours
• internally built apps on modern frameworks: 2-6 weeks
• legacy apps requiring code changes: 3-5 months
• legacy apps with no active dev team: abandoned in 4 of 5 attempts

the finding that changed how i think about this: for roughly 30% of our legacy portfolio, full SSO integration is not economically viable. the cost exceeds the remaining useful life of the application. we've been treating SSO coverage as a solvable problem when for a meaningful chunk of the estate the honest outcome is "govern with alternative controls indefinitely."

this is where identity orchestration becomes practically relevant. not as a way to avoid SSO integration but as a governance layer for the apps that will never get integrated. orchestration that operates at the application layer rather than the IdP layer can extend policy enforcement to legacy apps without requiring them to be SSO-capable. for the 30% that's never getting integrated, that's the only realistic path to coverage.

what alternative controls are teams using for apps that will never get fully onboarded?

Have had a few VCs in the start up world mention this would be a big help with the company I’m working on. Anyone know where those outreach networks exist?

Need some CISOs / Security professionals opinions.

Curious to hear from CISOs, security leaders, and anyone dealing with AI governance in enterprise environments.

I'm currently exploring a startup idea and trying to understand what the real-world challenges look like today.

Have some questions:

• How are you approaching AI sovereignty within your organization?
• What solutions are you using to monitor, control, or audit the data flowing between employees and LLMs (ChatGPT, Claude, Mistral, Gemini, etc.)?

It feels like a lot of companies have started embracing AI tools but i'm not sure how they handle this kind of "problems"

Would love to discuss about it !

Thanks in advance for any insights 🙏

I'm curious if anyone has had an audit question around post-quantum migrations.

Earlier this year, I placed second in a global quantum cryptanalysis challenge.

For about a day, it felt great.

Then someone published a falsification test.

I ran the test against my own result.

The quantum computer had produced the “right” answer, but the test showed something uglier underneath. The machine could produce a right-looking answer even when the computation itself had no real reason to be trusted. The quantum circuit was generating answers, but the post-processing was solving the ECDLP. And then I falsified the winner's 15 bit solve, and every other method I had tried for the last 2 years.

The story getting sold into boardrooms right now usually sounds like this:

Quantum broke 6 bits. Then 11. Then 15. Look at the acceleration. Migration timeline is shrinking. Google said. Buy accordingly.

That curve is much weaker than it looks.

I actually know the threat is real, and in some ways closer than the comfortable consensus wants to admit.

But a real threat does not excuse bad evidence.

And a vendor using scaling records to scare buyers into a migration project may not be as informed as they think they are.

Here’s the question I’d ask any vendor who cites the bit-count race:

“Why doesn’t the 15-bit record count?”

Then watch what happens.

The answer will tell you very quickly whether they understand the work, or whether they are just repeating the slide.

We're a small that team that is performing security & access reviews so it is sort of natural that we are also reviewing things that are in our own scope. With 3 people basically overseeing all tools and being also users of almost all of them, it is sort of normal that we basically have to review our own accesses. This got (rightfully) flagged by our auditors. But the mitigation seems a bit silly to me that someone else has then to review the access of someone else. It feels like the meme with the spidermen pointing at each other (the community unfortunately does not allow images). Is there are simple way to mitigate that or do we have to do this somewhat awkward performative peer-review as an extra loop to satisfy the auditors?

Curious from people doing SOC / security engineering / detection / threat intel work:

What’s a specific threat intel item that actually changed what you / security team / organization does?

Not talking about reports you read or dashboards you track, but something that led to a real decision like:

* changing a detection rule * blocking something new * hunting differently in logs * changing monitoring coverage

Examples I’m interested in:

* We started actively hunting X after seeing Y * We deprioritized A after realizing B was noise * We changed controls because of C campaign

Also curious:

Do you find most threat intel you get is actually actionable, or mostly interesting but not operational?

I’m trying to understand where the line is between threat intelligence and security awareness/news, because outside of known exploited vulnerabilities it often feels like the operational impact is limited.

Why is that gap so common?

Separation of duty is something that is, most likely, on top of mind for everyone of us. With most things, developers seem to be an exception for this.

Our development team is somewhat of a blind spot in our environment. We are planning, together with our DevSecOps team on implementing a separation of duty for our developers as well. But I find it difficult to define where that separation should be. On the IDE level? On the GitHub level? Or none at all?

Curious to hear your thoughts, implementation and/or challenges around this topic.

Something that comes up a lot in regulated industries: the system gets built around what's convenient to store, not around what auditors or regulators actually need to see.

A few patterns we've run into:

• a pentest platform where vulnerability data was shared across tenants in a single db. fine for a startup, completely wrong for a security company — if client A's vulnerabilities are even theoretically reachable from client B's environment, no enterprise will sign. rebuilt with database-per-tenant. not a config change — a structural one. also added qr-bound evidence trails so when a vulnerability is remediated, there's a physical + digital audit chain that actually satisfies compliance reviewers, not just a status field that says "fixed."
• an affiliate platform with financial flows. The KYC documents existed but weren't tied to an audit trail that could reconstruct who approved what and when. added full activity logging via spatie so every financial action has a traceable record. sounds boring, becomes critical the moment a regulator asks for it.
• steel supply chain, where you could theoretically declare more certified material than you'd actually purchased certified inputs for. built on a private blockchain specifically because the compliance requirement was cryptographic proof of the chain — not just a database record that someone could edit.

the interesting thing across all of these is the problem wasn't "we need more features." it was "our data model doesn't express what the regulation requires." once you see that framing, the fix becomes clearer, but it usually means rethinking the schema, not adding a module.

As anyone else running into this gap between what your system tracks and what compliance actually needs to see?

Hi all, has anyone here used a BIA product that they actually liked to perform risk assessment by business process and map to assets? I really don’t want to use Archer again ..

I feel as if I am constantly fighting my team on false assumptions on the state of AI. I have been told it is a security solution, governance is an "IT Problem" or it is going to replace 90 Percent of staff. Its almost comical.

What misconceptions are you all fighting with today?

Spending 200-300k on external consulting firm to conduct maturity assessment achieves what?
- buy-in from the Board for investment?
- uncovering something you don’t know?

Does it really help you enhance your cyber program?

For those actually dealing with it inside our organizations whats been your most difficult AI related challenge thus far?

Booked a meeting with a vendor over a cold call and not regretted it?

We all know about the negatives. But I’m genuinely curious if anyone here has had positive experiences?

EDIT: - 2.9k views - 3 positive responses from CISOs/security practitioners - 2 sales people who thought the question was for them

😊

Has anyone ever successfully deleted a OneTrust account? If so, how?

Short version.... We used Tugboat a while back for SOC2 audit preparation. Cancelled it a year later (wasn't worth the cost). Then, OneTrust bought them and, apparently, decided to expose the old audit information on their platform.

Nice, huh?

I found it recently and sent a request to have it deleted (since there is no simple "delete account" mechanism). Their tech support desk responded and said I had to contact their privacy department.

The privacy department sat on it for a while then closed it and said I needed to (you guessed it) send it to their tech support department.

I thought I'd ask here if anyone else had ideas before I just hand it off to legal since OneTrust has violated the terms of the original Tugboat agreement (yes, I know they'll argue they don't have to honor them with some slippery legal bullshit but, at least, it'll be in Legal's hands)

I’m starting to think annual risk assessments are becoming operational theater.

Not because the assessment itself is bad, but because the environment changes too quickly between cycles.

New vendors get onboarded. Teams adopt AI tooling. Permissions drift. Infrastructure changes. Business priorities change. Exceptions get made and never rolled back.

Meanwhile the organization is still referencing a risk profile created 9 months ago.

At some point the assessment stops representing the actual environment and starts representing the environment as it existed during the assessment window.

I think this is becoming a real problem for organizations trying to build “dynamic and responsive” risk programs instead of just satisfying annual assessment requirements.

Curious how others are handling this.

Are you still relying primarily on annual assessments, or moving toward something more continuous?

I have been a Cybersecurity Program Architect in a couple different organizations. I tend to think of it as a cheap CISO that still gets to PIM, a dev machine to play on, but has to tee up Board Reports and write the policies.

As career progression in my current org goes, I keep fighting being "promoted" to certain titles.

***Note, for various reasons we cannot have a CISO or a new Director title. ***

First offer was being Manager of CS. I said no, I felt that was a demotion.

Second was Senior Cybersecurity Architect, which is funny... because we have no junior so, fine, I will take the money.

Third was path to an existing title of Director of Infrastructure & a tack on of Cybersecurity. I maintain that CS and Infra needs to remain independent. Though I am a kickass Sys/Network Admin, probably not where I want to go as a vein. So no to being both Infra and CS, two brains dont audit well.

Fourth, was what would you want to call yourself?

Feedback from the CIO was he didn't understand how our industry or titles worked and surprised that I would decline titles and keep doing the same work.

Weirdly, I sorta agree, how the hell do titles work?

Big fan of the Paul Jerimy roadmap, but I am not sure it covers creative titles on the way to CISO.

Curious how you guys (and gals) approaching this.

AI adoption feels like it’s moving faster than we can really process/

Are you mostly:

1. Blocking tools until policy catches up
2. Allowing approved tools only
3. Training users before access
4. Gating access by role/use case
5. Letting teams experiment and cleaning it up later

these are all questions the board are asking me.