DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • The Cybersecurity Blind Spot in DevOps Pipelines
  • Cybersecurity Innovations in Software Development: How Developers Are Tackling Security Threats
  • Software Bill of Materials (SBOM): Enhancing Software Transparency and Security
  • 4 Essential Strategies for Enhancing Your Application Security Posture

Trending

  • Rust: The Must-Adopt Language for Modern Software Development
  • Parallel Data Conflict Resolution in Enterprise Workflows: Pessimistic vs. Optimistic Locking at Scale
  • How to Build a Real API Gateway With Spring Cloud Gateway and Eureka
  • Docker Model Runner: Running AI Models Locally Made Simple
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Essential Steps to Building a Robust Cybersecurity Team

Essential Steps to Building a Robust Cybersecurity Team

Learn how to build a resilient cybersecurity team — from hiring for mindset to embedding security into culture. Insights from Ozhan Sisic.

By 
Mykola Oliiarnyk user avatar
Mykola Oliiarnyk
·
Jun. 26, 25 · Analysis
Likes (1)
Comment
Save
Tweet
Share
1.1K Views

Join the DZone community and get the full member experience.

Join For Free

Cybersecurity doesn’t fail because someone forgot to patch a server. It fails because no one asked the right questions early enough, and because the wrong people were trusted to find the answers.

Most companies start building a cybersecurity team only after something breaks. A breach hits. Logs go missing. Customer data leaks. Then suddenly, there’s a mad rush to find “cyber talent” as if throwing more engineers at the fire will fix a decade of neglected fundamentals.

But security isn’t a department you build under pressure. It’s a system of thinking. One that lives in the habits, mindset, and collaboration of your team.

Ozhan Sisic gets this better than most. As former Director of Cyber Security at Jagex and with years of experience scaling global teams at Sony, he’s built security functions that don’t just respond to risk, but anticipate it. From hiring junior talent out of university programs to leading secure development frameworks and running global penetration testing programs, he’s seen what works and what burns out fast.

“You can’t buy security off a shelf. You build it. One mindset, one team, one system at a time.” — Ozhan Sisic

This article lays out the practical blueprint: how to hire people who think like both defenders and attackers, what roles you actually need, how to keep your team sharp, and why the way you lead matters just as much as the tools you deploy. Because great security isn't just about holding the line, it’s about understanding how someone might cross it.

Hiring for Mindset, Not Just Skillset

Most job descriptions in cybersecurity read like a shopping list: X years of experience, Y certifications, Z tools. But technical skills are only half the equation, and they age fast. What doesn’t? Curiosity, adaptability, and judgment under pressure.

“I don’t care how many certs someone has. If they can’t explain a risk to a product manager without causing panic, they’re not ready.” — Ozhan Sisic

When Ozhan built security teams at Sony and Jagex, he looked for minds that could flex: people who saw attack surfaces before they were formalized, who understood system design as much as they understood threats. He prioritized those who could collaborate with developers, challenge assumptions, and navigate complexity without ego.

Key traits he screens for:

  • Threat empathy: Can they think like an attacker and understand the business context?
  • Communication range: Can they shift from Slack threads with engineers to boardroom briefings without losing clarity?
  • Pattern spotting: Do they see the root cause, or just patch symptoms?
  • Learning velocity: Are they reading CVEs for fun? Do they get excited about tearing apart new tech?

And while the infosec world often leans into paranoia, Ozhan builds teams on trust and growth. He hires for potential, not perfection. “Give me a junior with grit over a ‘senior’ who’s coasting,” he says.

It’s not about lowering the bar. It’s about hiring for how someone thinks, not just what they already know. Because the next breach won’t care what was on your resume,  it’ll test how fast you can learn, adapt, and respond as a team.

Building the Core Team: Roles You Can’t Skip

There’s no universal formula for building a security team, but there are essential roles that act as the foundation. Without these, you're not building a security org,  you’re improvising defense.

Ozhan Sisic has built security orgs from the ground up, scaling from small in-house teams to 40+ person global functions. His approach is strategic: cover the critical surfaces first, then layer in specialization as maturity grows.

Here’s the core framework he recommends:

1. Security Architect

This is your blueprint strategist. They design how your infrastructure should be defended, long before the first vulnerability scan. A good architect understands cloud, network, and app-level security and knows how to bake controls into the system without slowing delivery.

“They’re your first layer of defense. If they get it right, you won’t need to fight a fire later.”

2. Security Engineer / DevSecOps

These are the builders. They integrate security controls into CI/CD pipelines, write and deploy policies as code, and create the tooling that makes secure development possible at scale. They’re often embedded within engineering teams to align security with delivery speed.

Tools they touch: Terraform, Kubernetes, Vault, IAM configs, SAST/DAST integrations.

3. Penetration Tester / Red Team

Whether in-house or external, you need people who can think offensively and who understand how real attackers move. Pen testers uncover flaws in systems, while red teams simulate persistent threat actors to test detection and response.

Ozhan emphasizes that this role only adds value when the organization is mature enough to fix what gets found. Otherwise, it’s security theater.

4. Incident Response and Detection Engineer

Someone needs to own the playbook when things go south. IR specialists build and maintain detection logic (SIEM rules, EDR configs, threat intel feeds) and respond to incidents with surgical focus. In early-stage teams, this role often overlaps with engineers, but formalizing it prevents chaos.

“Without response maturity, alerts become noise. And in a real breach, noise kills time.”

5. Governance, Risk, and Compliance (GRC)

Less flashy, absolutely critical. GRC professionals align your security practices with regulatory frameworks (GDPR, PCI-DSS, ISO27001), manage policy, and act as the bridge to legal and audit teams. They make sure you can scale without stepping on a landmine.

6. Security Program Manager

Once your team scales past 5–6 people, you need someone who can manage the moving parts. Program managers track initiatives, metrics, vendor management, budgets, and reporting. Without this role, your security team becomes reactive, not strategic.

How to Scale It

Ozhan advises starting lean, especially if you’re an early-stage or budget-bound. His ideal Phase 1 team?

  • One strong Security Engineer (with DevOps sensibility)
  • One Security Architect (ideally hybrid with IR)
  • A part-time GRC lead or external consultant
  • Access to on-demand pen testing support

Then, scale based on risk exposure and organizational complexity. Game studio? Focus on anti-cheat and data protection. SaaS? Double down on secure SDLC and access control. Regulated industry? Beef up GRC early.

“Don’t build for show. Build for your threat model. And build what you can maintain.”

Continuous Growth and Training Culture

The biggest lie in cybersecurity hiring? Thinking the job is done once the contract is signed.

Threats evolve. Stacks change. Tools get deprecated. If your team isn’t learning, they’re falling behind, and so is your security posture.

Ozhan Sisic has seen this firsthand. At Sony, he ran global secure development programs. At Jagex, he implemented training and awareness frameworks tailored to both engineers and security staff. Across both orgs, the lesson is clear: the best defense is a team that outlearns the attackers.

1. Certifications ≠ Competence

Plenty of candidates have letters after their names — CISSP, CEH, OSCP. These can be useful, but they don’t guarantee real-world skill. Ozhan values hands-on learning far more.

“I’ve hired people with zero certs who outperformed ‘experts’ with three. What matters is how they think and how fast they adapt.”

Encourage team members to experiment in lab environments, participate in bug bounties, and tackle internal CTFs (Capture The Flag competitions). It’s not about gamification, it’s about simulating threat pressure in controlled chaos.

2. Internal Knowledge Sharing

You don’t need a massive budget to build a learning culture. Ozhan recommends:

  • Monthly “Red Team Recaps” where attackers share findings with defenders
  • Internal “Lunch & Learn” sessions where engineers dissect breaches or toolkits
  • Secure coding clinics run in tandem with product teams

This keeps skills fresh and breaks silos between security and engineering.

3. Rotate and Cross-Train

Burnout in cybersecurity is real, and specialization without exposure can create blind spots. Ozhan rotates team members between domains: pen testers shadow incident response, GRC folks learn detection logic, and engineers help run tabletop exercises.

This cross-pollination creates empathy, flexibility, and resilience.

“You don’t want a team of heroes. You want a team where everyone understands the battlefield.”

4. Invest in Your Juniors

One of Ozhan’s long-term strategies is building talent in-house. He’s launched university partnerships, created internship funnels, and mentored juniors into senior roles.

Hiring a senior is expensive, and the talent pool is shallow. But training high-potential juniors? That’s how you build loyalty, culture, and long-term capability.

“The best defenders I’ve worked with started with zero work experience but endless hunger to learn.”

Fostering Collaboration and Cross-Functional Buy-In

Security teams don’t live in a vacuum. They sit at the intersection of engineering, product, compliance, IT, and leadership, and if they can’t work across those lines, security stalls before it even starts.

Ozhan Sisic has seen this dynamic at scale. His teams at Sony and Jagex weren’t just security silos, they were embedded partners in product cycles, infrastructure decisions, and corporate risk strategy. That didn’t happen by accident. It happened by design.

“Security fails when it’s a gatekeeper. It works when it’s a guide.”

1. Start With Shared Language

Engineers don’t want 10-page PDFs about ISO frameworks. Product teams don’t care about your SIEM dashboards. To earn buy-in, you need to speak their language.

Translate vulnerabilities into business impact:

  • “This token leak could expose 80% of user sessions” hits harder than “CVE-2023-XXXX found in module X.”
  • “We can’t ship this feature without logging because we’ll miss all breach indicators” is better than “Add telemetry.”

Ozhan trains his teams to write like product managers and talk like engineers. The goal? Make risk understandable, not intimidating.

2. Embed Security, Don’t Throw It Over the Wall

In mature setups, security engineers work side by side with product squads — reviewing code, guiding architecture, and solving problems in real-time, not after a failed pen test.

This model, often called Security Champions or Embedded Security, shortens feedback loops and builds trust. It turns security from blocker to enabler.

“If you’re catching flaws at the end of the sprint, it’s already too late.”

3. Tabletop Exercises and Blameless Postmortems

Running a breach simulation forces teams to work together under pressure, without the actual fallout. Ozhan leads tabletop exercises where product, engineering, and legal all play roles. Who talks to users? Who calls the DPO? Who patches the system?

Equally important: when incidents happen, postmortems are blameless by default. The focus is on systems, not scapegoats. That builds psychological safety and better incident response muscle over time.

4. Use Metrics That Matter to Stakeholders

Security metrics shouldn’t exist in a vacuum. Tie them to what your stakeholders care about:

  • For product teams: vulnerabilities per release
  • For engineering: MTTR (mean time to remediation)
  • For executives: risk reduction over time, not just “number of threats blocked”

Ozhan’s teams build dashboards tailored for each audience. No fear-mongering. No vague charts. Just a clear signal on where things stand and what’s improving.

“The goal isn’t to scare the business. It’s to help them make smarter bets.”

Managing for Long-Term Impact

Anyone can throw together a reactive security team. It’s easy to fight fires when your inbox is already smoking. But building a sustainable security function that scales, adapts, and holds under pressure? That takes a different mindset entirely.

Ozhan Sisic doesn’t measure success in how many threats were blocked this week. He measures it in how predictably his teams can handle the unknown. That requires strategy, structure, and the discipline to zoom out.

1. Operationalize Visibility

Security leaders often fall into two traps: too technical for execs, too abstract for engineers. One effective approach is to build layered dashboards tailored to each audience, offering clarity without overwhelming either side:

  • For the C-suite: “Here are the top 5 business risks, their exposure, and what we’re doing.”
  • For engineering: “These are the top 3 recurring security debt items slowing us down.”
  • For his own team: live telemetry, backlog triage, and incident drill performance.

This model proved successful at Sony, and it’s the kind of maturity more organizations are now working toward. These dashboards aren’t just reporting tools. They’re alignment tools keeping security tied to business context.

“You can’t manage what no one sees. Clarity is a force multiplier.”

2. Standardize Without Paralyzing

It’s tempting to build a fortress of tools, frameworks, and policies. But too much structure? You end up with shelfware and blind spots. Too little? You’re reinventing the wheel with every sprint.

Ozhan’s approach: standardize the bones identity, secrets management, secure SDLC, but leave room for teams to flex based on context. When leading global orgs at Sony, he enforced baselines (like code scanning and threat modeling) but let teams choose tools that fit their velocity.

“Every security team wants control. But good ones know where to let go.”

3. Vendor Management With Teeth

Buying security tools is easy. Getting them to work is another story. Ozhan insists on regular vendor reviews, KPIs tied to actual threat reduction, and clear accountability for delivery.

He’s also ruthless about ROI. If a tool adds complexity without payoff or doesn’t integrate cleanly, it’s out.

Tools must support strategy, not define it. If your tech stack looks impressive but slows down action, you’ve already lost.

4. People Over Panic

Finally, long-term impact comes from culture, not crisis mode. Ozhan invests in 1:1s, feedback loops, and performance coaching not just because it’s “nice,” but because high-trust teams move faster, recover quicker, and burn out slower.

“You can’t automate trust. And no dashboard will replace team morale.”

Final Thoughts

A cybersecurity team isn’t built on job titles, tech stacks, or tools. It’s built on a mindset. On clarity. On the daily discipline of people who choose to see the world differently, less as “secure” or “not secure,” and more as a living system constantly in flux.

Ozhan Sisic doesn’t preach magic formulas. He’s led security in industries where the stakes are high, the threats are real-time, and the attackers don’t care about your org chart. His core belief? That great security comes from smart systems, clear leadership, and teams who are trained to think, adapt, and collaborate.

“You don’t need superheroes. You need people who ask better questions, spot weak signals, and move fast together.” — Ozhan Sisic

So if you’re building your first security team or rebuilding one after a close call, remember this:

  • Hire for how people think, not just what they know.
  • Prioritize structure over noise, clarity over fear.
  • Invest in growth and collaboration, not just coverage.

Because in the end, the real strength of your security isn’t measured by how loud your alerts are. It’s in how quietly your team prevents problems the business never even sees.

security teams cybersecurity

Opinions expressed by DZone contributors are their own.

Related

  • The Cybersecurity Blind Spot in DevOps Pipelines
  • Cybersecurity Innovations in Software Development: How Developers Are Tackling Security Threats
  • Software Bill of Materials (SBOM): Enhancing Software Transparency and Security
  • 4 Essential Strategies for Enhancing Your Application Security Posture

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: