The New Commandments of Security Teams
Guest post by Maya Kaczorowski
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
This week, we have a guest post from Maya Kaczorowski. She is the cofounder of Oblique, a self-serve IGA solution. She’s one of the most impressive security product people I’ve met. In addition to being CPO at Tailscale and working on supply chain security at GitHub, she has a good sense of what personas struggled with what types of problems. Most importantly, she has a nuanced perspective on various security issues, which I find to be rare nowadays. We’ve discussed on multiple occasions how security needs to change and have had healthy debates, especially given that she has been on the selling side, and I’ve been on the buying side.
I asked her to guest post because she provides a different perspective from mine as someone who has seen different types of security teams. I told her to write from her perspective what makes security teams successful, and I thought it would be good for my audience to hear another opinion other than mine, i.e., for those religious followers, that security should be more of an engineering function. Although she graciously links to some of my articles, she does have a different take on how they are relevant to help existing security teams.
What we both agree on is that security needs to shift its mindset in this new world to scale and succeed; otherwise, they are going to be left behind and seen as a cost center rather than a value-add business partner. As a community, we need to start thinking more about how to actually solve problems rather than just surfacing them and forcing others to fix them. I appreciate that her approach, although strongly opinionated with firm principles, is actually practical. It gives me hope for the next set of startup founders working to solve security problems — creating new norms rather than perpetuating old ones that no longer apply. Reading through her article, I wonder if she’s better off running a security organization rather than selling to one!
The most successful security teams have quietly rewritten the rules of how they operate. They're not better at finding vulnerabilities, but they’ve changed how their organizations view security, becoming revenue enablers and strategic partners to other teams, most obviously to engineering.
These teams realized that being "the department of no" wasn't working and wouldn't scale. So they figured out what does work, and it’s how they run their security programs now. It's a complete mindset shift.
Here are the lessons they've learned that aren't yet widely adopted, but should be.
1. Security can be a sales enabler.
Security is generally seen as a cost center. When companies get breached, it doesn’t noticeably affect their market valuation. Security doesn't have a clear ROI, and some controls even have negative ROI, like requiring approvals for access, which definitely wastes time. So why invest at all?
Some companies see the opportunity: to use security to unblock revenue. This isn't just making security a product differentiator like choosing Signal over Messenger, but using security investments to unlock new revenue streams. There are whole companies built around this idea: that getting a compliance certification like SOC2 or FedRAMP will help you achieve other goals. But, we all know that security isn’t just compliance, and that compliance is the minimum bar, though it's a necessary investment to avoid having your business shut down when audits fail.
CISOs are learning to talk the language of the business because to get a seat at the board table, you have to be a business person, not a technologist. And so security teams are reprioritizing their roadmaps to align with business goals, working directly with GtM teams like Sales, Marketing, and Support because it means that they can actually get that item done, with more support, and faster. Adding SSO and SCIM means you can charge enterprise pricing. Writing that security whitepaper helps close deals faster. Improving the password recovery flow (or even better, adding passkeys) reduces the volume of support tickets. Even when you can't directly attribute revenue to security work, the business impact is obvious to everyone involved.
2. Your security problems aren’t unique to your organization.
Every organization thinks it's special, but it's really not. Security problems look remarkably similar across organizations of the same size, working in similar industries, or with similar kinds of data. The widespread adoption of cloud infrastructure and open source means most companies are running highly similar stacks. Unless you're doing something truly weird, your problems are the same as everyone else's.
This makes staying informed critical. Read blog posts 👋, go to conferences, lurk in private Slack channels. Someone else has definitely hit your problem before and probably wrote about it. Learn from them first instead of reinventing solutions.
You should only innovate where it matters in your organization's core business problem, which is probably not security. Please don't write your own secret manager when AWS Secrets Manager, Vault, or a dozen other options exist. Use what everyone else is using, and focus your limited time on the stuff that actually matters to your business.
3. Fix classes of problems.
Security debt is just another kind of technical debt. Engineers don’t ship the same code, with the same bug, dozens of times — they create a library. Security teams should think the same way: make larger investments that fix and prevent hundreds of little issues teams would otherwise have to address. The security industry is already familiar with some of these categorical solutions, like moving to memory-safe languages or adopting phishing-resistant authentication methods.
Security teams already have enough tools (and vendors) to find issues. What they need is help fixing issues at scale. This means thinking more like engineering teams: leverage engineering and automation to solve problems once, and reduce ongoing maintenance and manual processes. Security teams need to bring technical leadership and take the time to step back, not deal with whatever is currently on fire, and solve the bigger issues.
Where security teams often struggle is understanding what building a product actually means, in terms of investment and maintenance. Engineering teams don't think "I need a database, I'll build one myself.” Instead, they look at the market and figure out what to buy. Security teams aren't used to making build versus buy decisions and frankly (speaking), aren't great at it yet. They just haven’t built that muscle.
This doesn't mean security teams need to become engineering teams wholesale. We need both security engineering and security operations. But security teams do need to engineer more and get better at these strategic investment decisions.
4. Corporate security is real security.
For a long time, IT and security have been seen as separate capabilities. But your codebase is only as secure as your laptops. If an engineer's machine gets compromised, your source code, production access, and customer data are all at risk.
IT manages employee onboarding, devices, and password resets, but all of those have security implications, so we need to be looking at them holistically. Your identity provider, device management, and access controls are critical security systems. Managing them requires a team that understands security. This team needs to not only work well with engineering but also integrate with HR systems for seamless onboarding, ensure support teams can access customer data securely, and make sure the sales team actually uses SSO instead of sharing passwords. With more CISOs now reporting to the CEO and presenting to the board, the CISO and CIO are joining forces.
The old model of "security sets policy, IT enforces it" falls apart when these systems need expertise in both areas. We're finally acknowledging what should have been obvious: corporate security is security work, and a critical piece of it.
5. Prioritize vendor reviews.
Your organization has way too many vendors. Even with a vendor assessment program, you can't possibly review them all properly. Vendor security assessments have become completely useless: an LLM fills out the questionnaire, another LLM reviews it, and nobody learns anything or reduces risk. You spend more time managing vendor paperwork than managing actual risk.
Instead of aiming for perfect coverage, focus. Figure out your top assets and risks, then identify which vendors actually affect those. For critical vendors, e.g., ones with customer data or that can take down your infrastructure, go beyond questionnaires. Review their actual security practices and mitigate risks you're not comfortable with. You need to actually understand what you're signing up for. For everyone else? Accept the residual risk. SOC 2 report? Check. Move on.
6. Delegate authority, not just tasks.
For years, we’ve talked about “shifting left”: moving security responsibility earlier in the development process. While this has improved how security teams work with engineers, we’re realizing the more effective approach is building systems where secure development is the default path.
Instead of training teams to use security tools correctly, build infrastructure where the secure choice is the only choice (“guardrails”) or at least the easiest choice (“paved paths”). Engineers can focus on building features and automatically get security controls like proper authentication, or use secured infrastructure like sanctioned deployment pipelines. The dynamic is different: rather than asking engineers to do extra security work, we're designing their development environment to make insecure patterns difficult or impossible.
This means giving teams the ability to fix issues and handle exceptions themselves, within reasonable guardrails. If engineering wants to use a third-party library, they should be able to do so safely. If sales needs to grant a contractor access to lead data, or marketing wants to provision a laptop for a freelance writer, they should be able to do that, too.
Everyone knows what happens when the approved process is too slow or cumbersome: security gets circumvented entirely. We already accept this logic at the micro level. When someone clicks a phishing link, it's a failure of security controls, not the user. The same logic applies everywhere else.
7. Teach tradeoffs, not rules.
You can't do everything. Security leaders have learned to pick a few top realistic risks and protect against those well, instead of sweating the small stuff.
It’s important for leaders to lead by example and teach that skill to the rest of the security team. Security teams are often seen as just saying "no" and so being difficult to work with. But being empathetic is more effective. Taking the time to understand the business’s motivations, limitations, and priorities means that you can work with them better and still achieve acceptable and, even better, security outcomes with less pain. Just as med school students are being screened for their bedside manner rather than their knowledge of microbio, hire for individuals who ‘get’ the business context, and train for security expertise, not the other way around. One of those is much easier to teach.
Teach this mindset to the rest of the business, too. There will always be exceptions and compromises. Make reasonable decisions based on clear criteria and document the why of the decision, not just the decision. Teach judgment, not just policy. It helps people understand and make similar security-conscious decisions themselves, and identify where alternative solutions that would still meet the same goals exist.
8. Usability matters.
User experience matters because people have to use your security, whether they want to or not. If you don't build a security "well-lit path", someone will just find a desire path around your controls entirely.
Security needs to serve everyone. Your security tools need to be usable by the intern, not just the senior security engineer. This means thinking of every security product, feature, or service you build as more than just the technical implementation: consider the user experience, documentation, training, and ongoing support. Internal tools are often underinvested in compared to customer-facing products, but it's this last 10% of polish that makes all the difference.
Poor usability doesn't just create friction — it actively undermines security by incentivizing unsafe workarounds. A perfect technical solution that sits unused because it's confusing or slow is worse than no solution at all.
9. Results matter.
Some security teams think their job is to provide information: identify vulnerabilities, issue guidance, write policies, and send reports. But finding problems isn't the same as solving them. This is conflating activity with progress. It's security theater.
Security teams need to be effective, not just performative. Effective security teams measure themselves by actual risk reduction. This means defining clear metrics for a small, realistic set of priorities, then systematically improving those metrics over time. If you’re not above the security poverty line, start there.
If every other business function can measure results, security shouldn't get a pass with vague promises. The challenge is that security teams also need to educate executives and board members about how to measure security properly, but that's part of the job now.
The new rules in practice
These rules aren’t groundbreaking. They're just what works.
The shift is simple: instead of being the team that finds problems, become the team that solves them. Instead of just writing policies, build systems where the secure choice is the easy choice. Instead of reviewing every decision, give teams the tools and context to make good decisions themselves.
This is security finally operating like other mature business functions. The security teams making this transition are becoming indispensable business partners. The ones that aren’t are still explaining why security matters and will keep wondering why they're always fighting for resources and relevance.
The new commandments of security teams:
Security can be a sales enabler.
Your security problems aren’t unique to your organization.
Fix classes of problems.
Corporate security is real security.
Prioritize vendor reviews.
Delegate authority, not just tasks.
Teach tradeoffs, not rules.
Usability matters.
Results matter.