Hey all, long time lurker, first post in a while.

I’ve worked in industrial cybersecurity for over ten years, mostly in process industries. I used to think those sectors were behind. A while ago I moved to a large rail supplier in a senior role, and it’s been an eye-opener.

The pattern I keep seeing:

1. Selling cloud without design behind it: We offer cloud-connected products. When a client asks for a proper security architecture, they get marketing material. When they push back, the product and cloud teams won’t answer, and we’re told a real design document might expose proprietary info. These conversations drag on for months.

2. Compliance plans that depend on things that don’t exist: Regulator findings get “closed” on paper by pointing to an internal platform that isn’t actually deliverable. Someone in-country then has to rebuild the whole plan around off-the-shelf tools and risk acceptance.

3. Contracts nobody read: I’ve seen scopes where MFA and patching were excluded despite them being explicitly requested by clients just because they're not part of our technical solutions/deliverables, with nothing on backups or VAPT. The compliance matrix still said “fully compliant.”

4. Basics treated as controversial: I proposed a standard central-server-plus-agents AV setup. The answer was that the servers “can’t handle agents,” with no evidence. When I asked for some, it turned into a political problem for me and how I'm exposing the company and working against it.

5. Vulnerability management practices: only offering scanning without patching. Backup and restore is “not needed in rail.” Hardening happens during execution, maybe.

6. Rolling stock: We build the trains, and basic questions about the onboard network and its controls still don’t have clear answers. Imagine, this is coming from a train company that cannot explain the security of its core product!

The root cause is always the same. Bids are written centrally by people who don’t know the local regulations. Everything gets marked compliant to win, legal doesn’t check what’s being signed, and after award every gap becomes a “local issue.” Consortium deals get signed where we lead cyber with no staffing and no agreed scope split.

They tick “comply” on everything (ISO 27001, app whitelisting, SIEM integration, PAM) to win, and legal never checks what we actually signed up for. Brownfield scope gets done without site surveys (those fiber cables? estimated with 40% accuracy at best). After the award, every gap becomes “a local project issue.”

What wears me down isn’t the technical stuff, which I can fix. It’s that raising problems gets you labelled as not a team player, and staying quiet gets you told you’re not showing leadership. I’m effectively doing engineer, manager, and leadership work at the same time, and I’m running on fumes.

The part that actually burns me out: I asked for a GRC specialist, and my manager asked me what GRC means. I ran a lessons-learned session on how to bid cyber scope properly and was told “we’re a big beast, stop telling others how to do their job.” So I stopped pushing, and six months later my review said I need to “show more leadership and willingness to support the business.”

Honest question for people at rail suppliers, or OEMs in general: is this industry-wide? And has anyone seen a company actually close the gap between what tendering promises and what delivery can do, or does everyone just absorb it until they burn out?

TL;DR: Rail supplier sells cyber it can’t deliver. Integration with proper cybersecurity tools and technology is non-existent. Is this normal?

I've been in the big chair a while now and definitely feeling the burnout/impostor syndrome, but I'm making better money than I have in my life. For those that are still here on the sub but left the title, where did you go after and are you happier now?

Most of the social engineering conversation I see is about email: filters, simulations, training. But phones sit right next to it. Staff get SMS, WhatsApp and calls on the same device that holds their email, SSO and MFA approvals, and a lot of those phones are personal.
What I keep wondering is whether the phone becomes the bridge. Someone gets talked into approving an MFA prompt, tapping a link, or reading out a code, and that's the way into company systems.
Is this something you actually worry about, or is it covered well enough by MFA and training? And what do you do about attacks that arrive outside email, like texts, WhatsApp or phone calls, especially on BYOD?

Most AI-leak conversations I see are about browser and desktop: proxies, CASB, endpoint DLP. Phones feel like a blind spot to me. People open ChatGPT or Claude on their own device, and on BYOD you often can't see or control what goes in.
Is this on your radar, or is it a "later" problem?

Hi everyone,

I’ve recently been hired as a CISO for a small fintech company in the Middle East, and I’d appreciate advice from people who have been in similar roles, especially those who have built security programs from the ground up.

My background is primarily in cybersecurity GRC, audit leadership, and regulatory compliance. I’ve led audit teams, managed ISO 27001 and SOC 2 engagements, holds CISM, and worked on regulatory audits involving central banks and other regulatory authorities.

In my new role, the immediate expectation is to design and implement the company’s entire Information Security Management System (ISMS), meet applicable regulatory requirements, and ensure the organization is adequately protected.

I understand the GRC and compliance side reasonably well, but I want to approach this role correctly from a broader CISO perspective, particularly around technical security, operational risk, and building a sustainable security program in a small organization.

I’d appreciate insights on a few things:

1. First 90 days: What would you prioritize during your first 30, 60, and 90 days as a CISO in a small fintech?
2. Building the ISMS: How would you approach designing the program from scratch without getting buried in documentation and policies?
3. Technical security: What technical areas should I personally understand and validate first, particularly around cloud security, IAM, application security, monitoring, and incident response?
4. Regulatory compliance: How do you balance meeting regulatory requirements with implementing controls that genuinely reduce risk?
5. Limited resources: If you were the only dedicated security person, how would you prioritize work, leverage existing tools, and decide what to outsource?
6. Executive expectations: How do you demonstrate progress and communicate security risks to the CEO and board without creating unnecessary complexity?

I want to avoid that and build a security program that works in practice, not just on paper.

For experienced CISOs who have built security programs in fintechs or startups, what would you do differently if you were starting again?

Any practical frameworks, lessons learned, mistakes to avoid, or resources you would recommend would be greatly appreciated.

Thanks in advance!

We've noticed some nontechnical employees using coding agents and pasting API keys or others secrets directly into their prompts.

Our developers already follow proper secret management but the newer vibe coding crowd doesn't always know the risks

Has anyone else run into this? How are you keeping track of secrets and preventing them from ending up in AI tools without completely blocking people from using her?

Im just curious to get people's thoughts. In regulated environments... why do people think so highly of pentests and so little of compliance assessments, when they both do the same thing: determine if an organization is meeting its controls?

In all of the pentest engagements I have sat in, most of the findings are the same (unpatched server, app not upgraded, admin account creds cached on a box, legacy protocol not disabled). If orgs are not patching servers (or maybe they have a legacy box not being patched)... that would normally end up being caught on both engagements.

Both pentests and assessments are point in time. Pentests for my environment have typically been higher cost and only cover the technical side. So why do we look more favorably at one versus the other?

Anyone here working for a defense company and having to deal with CMMc/NIST requirements? Although the third party assessment have been postponed but would love to hear from anyone on what issues you see in getting this implemented in your company/client. Is it mostly budget related, complicated, no desire by management or… I have seen that there are many consultants out there and companies that will try and sell you something to get you ready but the sales tactics usually leave out the rest of the 100 controls e.g. put all your data into GCC high and you are CMMC complaint… frustrating to try and figure it out and having to check vendors as well.

I'm looking for recommendations and cost estimates for actual application pen testing. We've fallen into this trap where our pen tests are black box, narrow scope to pass SOC2 or ISO. I want to start course correcting and get meaningful data from white box testing to actually improve, not just a check box.

Is anyone here impressed with who they're working with currently? It's budget time so getting an estimate of price would be helpful even though I know price has too many variables to be accurate.

It has fallen on my shoulders to show my company's board and executives a return on their security spending. Is there a good way for me to collect and present metrics that show risk actually going down, not just activity?

The AI governance decision is rarely allow or block.

A more useful split is by capability and consequence. A tool that drafts internal text creates different risk from one that retrieves customer records, writes to a business system, approves transactions, or can trigger production actions.

The challenge is setting boundaries that are clear enough for teams to follow without creating a shadow AI problem.

For security leaders, which factor has been hardest to translate into an enforceable policy data sensitivity, agent autonomy, third party access, auditability, or accountability for decisions made with AI support?

I’ve been working through how I’d design authorization for enterprise AI agents, and I think there’s a tendency to make this more exotic than it needs to be.

My starting point would be: don’t create a parallel IAM stack just because the actor happens to be an AI agent.

Keep your existing IdP/IGA/PAM/PBAC as the authoritative control plane for identity, ownership, lifecycle, policy and privileged access. What changes is the execution model around the agent.

A few principles I’d use:

1. Give the agent an accountable identity where possible.

Every production agent should have an owner/sponsor, purpose, lifecycle state and attributable execution identity. But don’t assume every agent action will conveniently arrive as a clean service principal. Agents may operate through delegated tokens, other agents, MCP/tools, APIs, or even an authenticated human browser session.

2. Authentication should never imply authority to perform the task.
The useful authorization question isn’t “is this a valid agent?” It’s:
May this agent, acting for this user/service, under this task, perform this exact action against this resource right now?
Effective authority should be the intersection of the agent policy, task authority, delegating principal’s authority, resource policy and current risk/context, not simply whatever permissions the credential happens to carry.

3. Give the agent bounded task authority.

A task should have an issuer, acting agent, permitted actions/resources, expiry and delegation limit. The agent shouldn’t be able to expand its own authority just because its workflow changes.

4. Put enforcement immediately before consequential execution.
Before a tool/API/resource call executes, normalize the requested action and resource and evaluate policy against the exact request.
If the agent can reach the same target using another credential or route that bypasses that enforcement point, assume your enforcement is partial.
This gets particularly interesting with browser/computer-use agents because the downstream application may see a perfectly legitimate human session even though an agent actually generated the action.

5. Avoid standing target credentials where possible.
Broker bounded/short-lived access after authorization rather than giving agents reusable credentials and hoping upstream controls contain them.

6. Treat approval as step-up, not as the security model.
High-impact actions can require approval, but approval should bind to the exact action/resource/request and expire. The agent shouldn’t be able to approve its own request or turn one approval into broader authority.

7. Preserve execution provenance.
For consequential actions, I want to be able to reconstruct:
initiator → agent → task → authorization decision → approval/grant → target request → actual outcome
An IAM log showing that access was granted isn’t enough if I can’t establish what the target system actually executed.

8. Couple agent lifecycle to human and business lifecycle.
If an owner leaves, changes roles, a workflow is retired, or the agent’s purpose changes, that should trigger revocation or recertification rather than leaving another orphaned NHI behind.

To me, this is increasingly the distinction between agent identity and agent authorization/governance. Identity tells us what the agent is. The harder control problem is proving what authority this particular execution had and enforcing it all the way to the action.

I’ve been turning this into a vendor-neutral reference architecture, but these are the principles underneath it.

Hi, I know It sounds like a dumb question and even more as I'm an identity tool editor but still...how do you guys keep the records up to date regarding these NHIs and their privileges ?

Most Saas APIs only provide automation for "human users" although it's evolving quickly.

But do you stay update via "Manual tracking" or have you found some kind of "automated" workaround ?

I’ve been talking to people wiring hosted models into apps that already hold real customer records. What stalls isn’t model quality. It’s “which fields actually went out?” and nobody has a list. Do you redact in the app, rely on retention mode, put everything through Bedrock, or keep AI off the sensitive tables? Is a simple field allow/deny enough for legal, or do they only relax once processing stays inside the customer’s own service? Trying to understand what “good enough” looks like for teams without a security hire.

I’m leading security at a large enterprise with over 50,000 digital assets, and I’m trying to figure out AI pentests for the exposed infrastructure. The leading players I’ve looked at are crazy expensive and the scope is limited. you buy a few dozen targets and that's your program.

How do others here think about this at similar scale? Is anyone actually covering the whole surface, and is anyone pricing it in a way that survives five figures of assets?

Please delete if not allowed on here.

I’ve been working in information security for around 6 years and I’m currently an Information Security Officer. Longer term, I want to progress towards a BISO role and eventually CISO.
I’m at a bit of a crossroads with my development and would appreciate some perspectives from people who have made that transition.
My current role gives me exposure to areas including security risk, vulnerability management, client security engagements, RFPs/questionnaires, secure development, governance and working with both technical and business stakeholders.
The problem is that I increasingly feel siloed.
I’ve raised this internally and have repeatedly asked for opportunities that would give me broader exposure and help me develop beyond my current responsibilities. I’ve specifically said that I want to improve in areas such as executive communication, business engagement, security strategy and strategic thinking.
I’m also increasingly interested in AI security and governance. I’ve had people internally approach me for help with AI-related security questions, and I’ve started thinking about how security teams can provide more consistent governance and support as businesses adopt AI.
However, some of that development has effectively been parked for now.
The main direction I’ve been given is to focus on completing my CISSP, which I’m currently working towards. I absolutely see the value in doing that, but I’m conscious that getting the certification alone isn’t going to give me the strategic, business-facing and leadership experience I’ll eventually need for BISO/CISO roles.
I don’t expect to jump straight from ISO to CISO, and I know there are development steps I need to take. What I’m trying to work out is how best to spend the next 6–12 months.
For those who have moved from operational/technical security roles into BISO, security leadership or eventually CISO positions:
What experiences made the biggest difference to your progression?
Would you prioritise the CISSP first and then broaden out, or deliberately develop the strategic/business side alongside it?
How did you get meaningful strategy and executive exposure when your existing role wasn’t naturally giving you enough of it?
And at what point would you decide that you’ve exhausted the development opportunities available internally and need to look elsewhere?
Interested in hearing from people who have made a similar transition.

I've been talking with a lot of part-time and fractional CISOs lately, mostly people covering 5 to 15 SMEs or small public bodies each. NIS2 is changing that job in ways I don't see discussed much.

Before, a fractional CISO for a 50-person company was mostly advisory: a policy set, an annual risk review, awareness training, being on call when something went wrong. Now a lot of those clients are in scope, as "important" and sometimes "essential" entities, and the expectations have moved:

• Management accountability is personal. Leadership has to approve the measures, oversee them and get trained. So the fractional CISO ends up running board-level governance for every client, not just writing documents.
• Incident reporting needs a real process. An early warning within 24h and a notification within 72h. Who makes that call at 2am for a client you see two days a month?
• Evidence has to hold up over time. One assessment a year doesn't show continuous improvement.

What I keep hearing from people doing this job:

1. The same 10 to 15 gaps come up at almost every client (admin MFA, tested restores, asset inventory, supplier access, logging), so the work gets repetitive. But each client still needs its own risk context, or it becomes a tick-box exercise.
2. The deliverables are what eat the time. Not the thinking, but rebuilding the same gap analysis, action plan and board report in a slightly different shape for each client.
3. Pricing hasn't caught up. Clients still budget "a few days a month" while the regulatory load has clearly gone up.

For those of you working this way:

• How do you structure your portfolio so shared work gets reused without clients feeling they're getting a template?
• How do you handle the 24h reporting obligation for clients you're only with part-time? Is it in the contract, with an on-call arrangement, or delegated to their MSP?
• Have you changed your pricing since NIS2, or are you absorbing the extra work?