While I'm thinking about work, a piece of advice for startups thinking about security: fix your project management and roadmapping process before/at the same time as bringing someone in to help with security, especially if that person is not getting put in as a peer to the CTO with the swing to force stuff onto the roadmap.

When I come in as a fractional CISO, I am almost always the first stakeholder with significant engineering requirements that are not coming from the product roadmap. In most cases, there is not yet a clear way for the organization to make decisions about what to do with competing priorities that lives outside of the head of the product owner. This means that even generally agreed high priority work — on the level of "perhaps we should consider backing up the production data without which the entire business is gone" — struggles to get done in the face of this quarter's feature plan.

Talking about this in my kickoff meetings and getting very explicit commitments from the executive team early on as to how they want me to proceed with decision-making helps a little. The only places I've seen where it hasn't been a problem are all companies that have been able to hire their way out of it. "Wow, doing that security infrastructure work would take like 20% of our entire engineer team for two years. I guess we better grow the engineering team by 20% and dedicate those people to security work." While great for me when I get to work with those teams, this is not a general solution to the problem.

0

If you have a fediverse account, you can quote this note from your own instance. Search https://infosec.exchange/users/dymaxion/statuses/115604224832133544 on your instance and quote it. (Note that quoting is not supported in Mastodon.)