Head of Security

About Divar. Millions of people use Divar to buy, sell, rent and hire. We run most of the platform ourselves: bare-metal and virtualized infrastructure across several data centers, Kubernetes, Go and Python microservices, Kafka, a range of SQL and NoSQL databases, distributed storage, and our own CI/CD — plus Android, iOS and web clients. That makes securing it our job too.

How security works at Divar. Each infrastructure and product team owns the security of what it builds and runs. A security chapter — engineers who sit inside the infrastructure, backend, mobile, and web tribes — sets the bar with them, helps them meet it, and checks the result. Platform teams turn recurring controls into safe defaults. Specialist work such as incident response retainers, threat hunting, forensics, and red teaming is done with outside partners, under our direction and without standing access.

The role. You lead the security chapter and own Divar's security program end to end: the standard, the roadmap, the risk register, and the results. You report to the CTO, meet the CEO in a quarterly security steering review, and can take a critical risk straight to the founder when it isn't being addressed.

What makes a Head of Security at Divar?

• You're an engineer first. You can review a Kubernetes admission policy, a CI runner's isolation, or a backup design and tell whether it actually protects anything.
• You think about risk, not checklists. 100% compliance isn't the goal. You choose controls that reduce real risk, and you document the risks we accept, who owns them, and when we'll review them again.
• You measure progress. "We're hardened" isn't an answer. "73% of CIS Level 1 controls pass, and every failure has a documented exception" is.
• You lead through people you don't manage. Chapter members report to their tribe leads; system owners report to theirs. You make the model work through clear standards, agreed priorities, and follow-through.
• You plan for the worst. Data loss, losing a data center, power shortages, or losing international connectivity are scenarios you plan for and practice, not footnotes.
• You're honest about trade-offs. You can tell leadership what a decision costs in risk, money, and team capacity, and you're willing to say "not now."

Your first year

• Month 1: Get to know the people, products, and stack. Review the security roadmap already underway across the datacenter, production platform, CI/CD, data, and client teams. Check its metrics and name the top risks.
• Months 2–3: Take ownership of the roadmap. Get the security charter approved: company-wide standard, exception process, risk acceptance, and remediation deadlines. Agree each chapter member's priorities with their tribe lead. Put the incident response partner under contract.
• Months 4–12: Security posture is measured and reported every quarter. Asset inventory is complete and visible. Recovery drills run on a schedule. Hardening reaches the remaining data stores. Security is part of every design review and every release gate. By then we'll rely on your judgment to tell us what comes next.

We'll judge your success by how much risk goes down and how much more resilient we become, not by how many policies or tools you introduce.