Security culture is one of those things that’s easy to agree with in principle and hard to implement in practice. Every founder nods along when someone says “security should be everyone’s responsibility.” Fewer founders can describe what that actually means for their team on a Tuesday afternoon.
This post is about what a security-first culture looks like at an Israeli tech company of 10 to 100 people, and how to build it without turning it into a compliance exercise that everyone ignores.
Why Culture Matters More Than Controls
You can deploy MFA, set up a SIEM, and hire a security consultant — and still have a team that texts AWS credentials to each other over WhatsApp.
Technical controls are necessary. But they’re not sufficient. The decision-making that happens in the gaps between your controls — the developer who disables an S3 bucket policy to make a demo work, the founder who reuses a password across accounts because they’re busy, the engineer who approves an OAuth request without reading the scopes — that’s where culture operates.
At an Israeli startup, the stakes are concrete. You’re likely handling sensitive customer data. You may be subject to Amendment 13, INCD guidelines, or international compliance frameworks. You’re a target for threat actors who understand the value of what you build. A security incident at the wrong moment can derail a fundraising round, cost a major customer, or trigger regulatory enforcement.
What Security Culture Is Not
Before building the right thing, it helps to name the wrong things:
- It is not an annual security awareness training — a one-hour video your team clicks through and immediately forgets does nothing
- It is not the security team’s problem — if only one person cares about security, that person cannot possibly maintain it
- It is not a checklist — compliance is a byproduct of culture, not a substitute for it
- It is not a paranoid culture — fear-based security cultures breed workarounds. People will route around security controls that feel arbitrary
What Security Culture Actually Looks Like
Security is part of how you build, not a step before you ship
When developers open pull requests, do they think about what access the new code needs? When product managers write specs, do they include data classification requirements? When engineers spin up infrastructure, do they start from least-privilege?
This doesn’t happen automatically. It happens when leadership demonstrates that these questions matter — by asking them in code reviews, in design reviews, and in postmortems. The founders set the standard for what gets questioned and what gets waved through.
Security decisions are visible and explained, not handed down
When you enforce a new control — requiring YubiKeys for production access, for example — explain the threat it addresses. “We’ve seen credential theft used to compromise companies at our stage. This makes that attack significantly harder.” A team that understands the why will respect the control. A team that gets a policy memo will work around it when it’s inconvenient.
Near-misses are shared, not hidden
Every security near-miss — the phishing email that almost worked, the misconfigured S3 bucket that got caught in review, the contractor with too-wide permissions — is a learning opportunity. Create a low-blame environment for surfacing these. If team members fear punishment for reporting a mistake, near-misses stop getting reported. Then you find out about them after they become incidents.
Security responsibilities are defined, not assumed
“Everyone is responsible for security” is true but unhelpful without specifics. Define who reviews access grants, who approves new SaaS tool adoption, who rotates credentials and when, who is contacted first if someone suspects a phishing attack. These responsibilities should be in onboarding materials and updated as the team grows.
Practical Steps for Founders
1. Own your AWS root account personally, and lock it down appropriately. The root account should have MFA, should not have access keys, and should almost never be used. If you’re using it for day-to-day operations, fix that today.
2. Set a default of “ask before connecting.” New SaaS tools, new integrations, new contractors asking for access — these should go through a lightweight review before they get access to your systems. Not a bureaucratic approval process, but a “does this need the access it’s asking for?” conversation.
3. Run a quarterly access review. For a team of 10-50 people, this takes an hour. Review who has admin access to what, revoke anything that’s no longer needed, and check contractor and vendor access. Make it a recurring calendar item.
4. Simulate phishing once a year. Send your team a test phishing email and measure the click rate. This is not about punishing people who click — it’s about calibrating your risk. If 60% of your team clicks, you have a problem that technical controls alone won’t solve.
5. Write a “what to do if” guide. What does a team member do if they think they’ve clicked a phishing link? What if they find an access key in a public repository? What if a customer reports suspicious activity? This guide should be one page, easy to find, and updated when procedures change.
The Compounding Effect
Security culture compounds in both directions. Teams that build good habits early find it progressively easier to maintain them as the company grows — new hires learn from existing practices, controls get stronger as the team matures, and security incidents stay rare. Teams that defer the culture-building find it exponentially harder to retrofit, especially after a painful incident forces the issue.
Israeli founders who are building companies that will handle sensitive data, operate in regulated sectors, or pursue enterprise customers are making a bet every day on whether their security culture is strong enough. It’s worth building it deliberately rather than finding out where it breaks.
If you want to talk about how Xpernix can support your security operations as your team grows, contact us.