Security leadership is often described as risk management, but in practice it is translation.

The security leader sits between groups that all care about the same organization, but rarely speak the same operational language. Legal needs defensibility. Product needs velocity. Engineering needs clear requirements. IT needs controls that can actually be operated. Executives need risk visibility without drowning in technical detail.

When security cannot translate between those groups, the program becomes fragmented. Legal sees unresolved exposure. Product sees blockers. Engineering sees vague mandates. IT inherits tools and processes without enough ownership clarity. Executives hear that “risk is being managed,” but cannot tell whether the organization is actually becoming more resilient.

The real work of security leadership is to make risk understandable, actionable, and measurable across each function.

That does not mean softening the message. It means making the message useful.

Legal needs defensibility

Legal does not need security to recite framework language. Legal needs to know whether the organization can explain its decisions, prove its controls, and demonstrate that privacy and security obligations were translated into actual operating practices.

That matters especially in education technology and SaaS environments where customer trust, student data, privacy laws, and vendor obligations intersect.

The FTC’s action against Edmodo is instructive. The FTC said Edmodo violated COPPA by collecting personal information from children without proper parental consent and by improperly shifting compliance responsibility to schools. The lesson is not simply “know COPPA.” The lesson is that privacy obligations must become product requirements, consent workflows, retention rules, vendor terms, and evidence the organization can defend later.

A security leader serving Legal well would not stop at asking, “Are we compliant?” The better questions are: What data do we collect? Whose data is it? What authority do we rely on to collect it? How long do we retain it? Who can access it? What evidence proves the control is working? What would we show a regulator, customer, school district, or auditor if challenged?

Legal needs defensible facts, not security optimism.

The Uber case makes the cost of misalignment visceral. When a breach affecting 57 million users was discovered in 2016, the security team structured the attacker payout through the bug bounty program and did not surface it through legal counsel as a regulatory disclosure event. The company was already under an active FTC investigation. The result: then-CSO Joe Sullivan was convicted of obstruction of justice and received three years of probation. What made the situation catastrophic was not the breach itself. It was that security and legal were operating on entirely separate assumptions about what the event meant and who needed to know.

Chegg reinforces the point from the other direction. The FTC finalized an order with Chegg after alleging that poor data security practices exposed sensitive information about millions of customers and employees across multiple breaches over several years. For a security leader, the lesson is that repeat findings, unresolved gaps, and weak remediation discipline can become legal and reputational exposure over time.

The translation for Legal is straightforward: security risk becomes legal risk when the organization cannot show that known issues were identified, prioritized, remediated, and monitored. A standing framework for incident classification and disclosure timelines, built before anything goes wrong, is the foundation of that trust.

Product needs velocity

Product teams do not want to ignore security. They want to ship valuable work without being surprised late in the cycle by vague, subjective, or constantly changing requirements.

Security earns trust with Product by making the secure path the clearest path.

That means defining privacy and security expectations early enough to influence design. It also means separating true launch blockers from issues that can be risk-accepted, time-boxed, or handled through compensating controls.

For example, if a product team is launching a new feature that handles student or educator data, security should be able to provide clear decision support: Does this introduce a new data category? Does it change the purpose of collection? Does it affect a school district’s contractual commitments? Does it require consent, notice, or retention changes? Does it introduce a new vendor or integration? Does it require additional logging, access controls, encryption, or review?

That is not bureaucracy. That is product risk management.

The Equifax breach of 2017 illustrates what happens when that translation breaks down at scale. A patch for the Apache Struts vulnerability exploited in the attack had been available since March of that year. The breach ran undetected from May through July. The post-incident record describes fragmented responsibility between IT operations and engineering, unclear ownership over which team patched which system, and a failed certificate scan that left the vulnerability undetected for 145 days. Approximately 147 million people had their personal information exposed, and the company ultimately spent over $300 million in recovery. What failed was not awareness that the vulnerability existed. What failed was the internal process for translating a known risk into a clear, owned, sequenced task with a delivery date.

Netflix built one of the most cited countermodels. Former VP of Information Security Jason Chan developed what the security team called the “paved road”: centralized, secure-by-default frameworks, authentication libraries, certificate management tooling, and deployment pipelines that engineers could adopt with minimal friction. The insight was simple: if the secure path is also the easiest path, adoption follows naturally. Engineers retained the autonomy to go off the paved road, but they became responsible for the full operational burden of doing so. The incentive structure rewarded security without mandating it.

Atlassian’s public shared responsibility materials reflect the same philosophy at the customer-facing level. Atlassian explains what it owns versus what customers own, giving Product, Legal, Customer Success, and IT a common operating language for responsibility. Security leaders should bring that same clarity inside their own organizations. Product should never have to guess where security responsibility sits. Velocity improves when teams know what good looks like before the release is already in motion.

Engineering needs clear requirements

Engineering does not need abstract warnings about “cyber risk.” Engineering needs requirements that can be built, tested, verified, and maintained.

“Improve access control” is not an engineering requirement.

“Administrative access must be role-based, time-bound where possible, logged, reviewed quarterly, and tied to an approved business justification” is closer to something Engineering can implement and something IT can operate.

“Shift left” is not a plan.

A real secure SDLC plan defines where security work happens, who owns it, and what evidence is produced. It may include threat modeling for higher-risk features, dependency scanning, static analysis, secrets detection, infrastructure configuration checks, penetration testing intake, remediation SLAs, and release criteria for critical vulnerabilities. The key is not to bury Engineering in security theater. The key is to turn risk into clear acceptance criteria.

Microsoft’s Secure Future Initiative, launched in November 2023, is one of the most public examples of a major organization restructuring around exactly this. The SFI assigned engineering owners to each of six security pillars and expressed objectives as specific, measurable standards rather than policy statements. The CISO organization repositioned itself as a partner to engineering rather than a gate over it, with regular reviews between security governance and engineering executive vice presidents. Microsoft has publicly described mobilizing the equivalent of 34,000 full-time engineers toward security objectives framed as engineering problems. The result was governance embedded into engineering cadence rather than layered on top of it as an audit function.

If an organization is preparing for SOC 2, ISO 27001, NIST alignment, or customer security reviews, Engineering should understand which controls affect their workflow and why. Evidence collection should not be an annual scavenger hunt. It should be designed into the way work is planned, shipped, monitored, and reviewed. Controls must be strong enough to satisfy risk and compliance needs, but specific enough that Engineering can act on them without guesswork.

IT needs operable controls

IT is often where security ideas become operational reality. That is why security leaders must be careful not to create controls that look good in a policy document but fail in day-to-day execution.

Identity and access management is a clear example. A policy may say that access must follow least privilege, but IT has to make that real through provisioning workflows, role design, access reviews, privileged access controls, joiner-mover-leaver processes, and exception handling. Privileged access management is not just buying a vaulting tool. The organization needs entitlement standards, onboarding procedures, break-glass rules, session monitoring expectations, ownership models, and audit evidence.

IT needs security direction that is operationally sustainable.

AWS has built one of the most widely adopted models for this relationship through its approach to security guardrails. Rather than requiring teams to manually review configuration standards across hundreds of accounts, AWS provides infrastructure-as-code validation, service control policies, and automated remediation through native tooling. CloudFormation Guard validates templates against security policy before deployment, blocking misconfigurations at the source rather than catching them in audit. The explicit design philosophy: guardrails, not gates. The goal is to enable velocity while enforcing security floors through automation rather than review queues.

The same logic applies to security awareness, endpoint controls, logging, incident escalation, vulnerability remediation, and vendor onboarding. If security designs controls without IT’s operating reality in mind, the program creates resentment and inconsistent execution. Every control should carry an operational spec alongside its security rationale: How is this monitored? Who gets alerted when it fires? What is the remediation playbook? What is the expected helpdesk volume? Controls that arrive without operational specs create shadow workarounds.

The better approach is genuine partnership. Security defines the risk and the control objective. IT helps define the implementation path, support model, workflow, tooling constraints, and maintenance burden. Together they define the metric that proves whether the control is working.

Executives need risk visibility

Executives do not need every technical detail. They need enough clarity to make decisions.

That means security reporting should answer five questions: What is the risk? Why does it matter to the business? What is being done? Where are we blocked? What decision or investment is needed?

The SEC’s 2024 charges against Unisys, Avaya, Check Point, and Mimecast are a useful reminder that cybersecurity communication cannot minimize or obscure material risk. The SEC said those companies made materially misleading disclosures related to cybersecurity risks and intrusions connected to the SolarWinds Orion compromise. Whether an organization is public, private, nonprofit, or mission-driven, the leadership lesson is the same: executive reporting must be accurate, timely, and grounded in evidence.

Security leaders create value when they give executives a truthful view of risk without dramatizing it. That requires metrics that show movement, not noise. Useful examples include control implementation by framework area, high-risk findings past SLA, privileged access exceptions, vendor assessment aging, incident response tabletop findings, phishing susceptibility and reporting behavior, audit evidence completion, critical vulnerability remediation time, policy exceptions by business owner, and risk acceptance decisions requiring renewal.

Phil Venables at Google Cloud has described this framing consistently: speak in business outcomes, not security metrics. Instead of reporting the number of vulnerabilities remediated, show the change in breach probability and the estimated financial exposure avoided. Instead of listing controls implemented, show the coverage gap that remains and the resource investment required to close it. That maps directly onto how boards and executives think about capital allocation and fiduciary responsibility.

Good reporting does not just say, “We are working on security.” It says: here is the maturity baseline, here is where exposure remains, here is what improved, here is what requires leadership support, and here is what we will measure next.

Security leadership is cross-functional trust-building

The strongest security programs are not built by fear, tool sprawl, or policy volume. They are built through trust, clarity, and execution.

Legal trusts security when obligations are translated into defensible controls. Product trusts security when requirements are clear early enough to preserve momentum. Engineering trusts security when risk is converted into actionable work. IT trusts security when controls are practical to operate. Executives trust security when reporting is honest, measurable, and tied to business impact.

The organizations that do this well do not have fewer incidents. They have faster, better-coordinated responses when incidents happen. They have legal counsel who trusts the security team’s judgment on disclosure. They have product teams who treat security requirements as first-class engineering work. They have engineers who know how to ask for help. They have IT teams who own and operate controls reliably. And they have executives who can make risk decisions with confidence.

A mature program is not measured by how many policies exist. It is measured by whether the organization can make better decisions, prove its controls, reduce risk, and protect the people who depend on its products.

That is where security becomes more than compliance.

It becomes organizational trust.

Kimly Hong is a cybersecurity professional specializing in identity and access management, governance frameworks, and enterprise security program development. With hands-on experience implementing IAM solutions across complex regulated environments, Kimly works at the intersection of identity security, compliance, and business enablement.

Connect on LinkedIn or www.kimlyhong.com to continue the conversation