{"id":22,"date":"2026-07-10T20:45:29","date_gmt":"2026-07-10T15:15:29","guid":{"rendered":"https:\/\/thehackerbuild.com\/blog\/?p=22"},"modified":"2026-07-10T20:45:30","modified_gmt":"2026-07-10T15:15:30","slug":"security-programme-without-a-security-team","status":"publish","type":"post","link":"https:\/\/thehackerbuild.com\/blog\/security-programme-without-a-security-team\/","title":{"rendered":"Security Programme Without a Security Team: An Engineering Leader’s Guide to Building One from Scratch"},"content":{"rendered":"\n

You have been handed security ownership alongside delivery. Here is where to start \u2014 and what the generic frameworks will not tell you.<\/strong><\/p>\n\n\n\n

By Shashijeevan M. P. \u2014 VP of Delivery | CEH | M.Tech, IIT Kharagpur | thehackerbuild.com<\/em><\/p>\n\n\n\n

\n\n\n\n

There is a moment that many engineering leaders recognise immediately when they hear it described. You are in a leadership meeting \u2014 focused on delivery timelines, team scaling, and platform reliability \u2014 when your CTO or CEO turns to you and says: “We need someone to own security. You have the most technical depth in this room.”<\/em><\/p>\n\n\n\n

On good days, that sentence sounds like trust and opportunity. On honest days, it sounds like an unfunded mandate with no clear starting point.<\/p>\n\n\n\n

I have been in that moment more than once across a 28-year career in enterprise software, leading engineering teams across India and the US in GICs and GCCs across different sectors. Security ownership has been one of the most challenging \u2014 and ultimately most rewarding \u2014 aspects of engineering leadership. Not because the technology is impenetrable, but because building a security programme while simultaneously running delivery at scale is genuinely hard. The frameworks are written for security specialists. The textbooks assume you have a dedicated security team. Neither describes the reality facing most engineering VPs today.<\/p>\n\n\n\n

This article is for you if you have found yourself in that meeting \u2014 whether you are leading a GIC in Hyderabad, a GCC in Bengaluru, a product engineering team in Pune, or a distributed engineering organisation anywhere that owns security without a dedicated function to run it.<\/p>\n\n\n\n

\"article1<\/figure>\n\n\n\n
\n\n\n\n

Section 1: The Programme You Inherit vs. The One You Build<\/h2>\n\n\n\n

Building from scratch almost never means starting from nothing. It means starting from chaos.<\/p>\n\n\n\n

Most organisations that appoint an engineering leader as their de facto security owner have been operating for some time. There are already tools in place \u2014 perhaps a firewall, an antivirus subscription, some kind of endpoint management. There are probably processes too, though they exist mostly in people’s heads. And there is technical debt: servers without patches, access rights that nobody has reviewed in three years, a CI\/CD pipeline where secrets are stored as plaintext environment variables because it was the fastest way to ship at the time.<\/p>\n\n\n\n

This is the programme you inherit. And it is almost always more dangerous than building from zero, because the existing controls create a false sense of coverage. The firewall is running, so the network must be protected. The antivirus is installed, so endpoints must be safe. Neither statement is true, but both feel true until the day they are not.<\/p>\n\n\n\n

In 2026, this challenge has a new dimension. Your organisation’s existing programme may already include LLM inference endpoints serving production features, MCP servers connecting AI agents to internal data, RAG pipelines processing customer documents, and agentic workflows making autonomous API calls. None of these appear in most security baseline checklists. None of them existed when most compliance frameworks were last meaningfully updated.<\/p>\n\n\n\n

The first question is not which framework to adopt. It is not which tool to buy. The first question is brutally simple: what can actually hurt us in the next ninety days?<\/strong> Answer that honestly, and everything else follows.<\/p>\n\n\n\n

\n\n\n\n

Section 2: Step Zero \u2014 Know What You Are Protecting<\/h2>\n\n\n\n

Controls applied to an unknown asset landscape are guesswork dressed as governance. Asset management is not glamorous. It is the work that makes everything else possible.<\/p>\n\n\n\n

In an engineering organisation operating across geographies, an asset inventory means more than a list of servers. It includes four distinct categories that most programmes address incompletely:<\/p>\n\n\n\n

Compute assets<\/strong> \u2014 cloud instances, Kubernetes nodes, serverless functions, container images in production and in your registry. In a cloud-native environment, your asset boundary changes with every deployment. Pods are ephemeral. Namespaces expand. New Helm charts get installed by developers solving an immediate problem. Your inventory must be continuous, not a quarterly spreadsheet exercise.<\/p>\n\n\n\n

Data assets<\/strong> \u2014 where sensitive customer data lives, where transaction records are stored, which services process regulated information, and which databases would trigger notification obligations to your regulators if compromised. Whether you operate under RBI guidelines, HIPAA, GLBA, or the DPDP Act, the data classification question is the same: which of our assets, if breached, creates a regulatory notification event? That data requires your most stringent controls.<\/p>\n\n\n\n

Identity assets<\/strong> \u2014 service accounts, developer credentials, CI\/CD tokens, cloud IAM roles, API keys stored in environment variables, and the growing category of AI service credentials: API keys for LLM services, vector database tokens, model registry credentials. Every credential is an asset. Every credential without an owner and a rotation schedule is a liability.<\/p>\n\n\n\n

AI and integration assets<\/strong> \u2014 LLM API connections, MCP server endpoints, RAG pipeline components, third-party AI services integrated into your products. These are attack surfaces with unique risk profiles: prompt injection, model exfiltration, supply chain compromise of AI libraries, and unauthorised data ingestion through retrieval pipelines. Most asset inventories miss this category entirely in 2026.<\/p>\n\n\n\n

The Asset Sprint:<\/strong> Block one working day. Pull your cloud resource inventory. Query your Kubernetes clusters for all running workloads across all namespaces. Run a search across your code repositories for environment variable patterns that look like secrets or API keys. Export all IAM users and service accounts. Ask every development lead to list every third-party API their services call \u2014 including AI services.<\/p>\n\n\n\n

What surprises you in that output is your first risk list. Every unexpected asset \u2014 the forgotten cloud instance from a proof of concept, the service account with administrator access that nobody can explain, the developer laptop with production credentials last seen eight months ago \u2014 is a potential exposure you did not know you had.<\/p>\n\n\n\n

Once you know what you have, the second step is data classification. Not every asset carries the same risk. A static documentation site and a database containing regulated customer records require fundamentally different controls. In an India\/US dual-jurisdiction environment, your classification must account for both your Indian regulatory obligations (RBI, DPDP Act, CERT-In reporting requirements) and your US parent company’s framework (SOC 2, GLBA for financial services, HIPAA for healthcare, PCI-DSS if you process payments). Getting this wrong is not an audit problem \u2014 it is a breach notification problem.<\/p>\n\n\n\n

\n\n\n\n

Section 3: Risk First, Compliance Second \u2014 A Practitioner’s Argument<\/h2>\n\n\n\n

The canonical debate in security programme design is whether to start from risk analysis or from a compliance framework. Here is my direct answer, earned across multiple programme builds in engineering organisations of different sizes, sectors, and regulatory contexts:<\/p>\n\n\n\n

Use NIST CSF 2.0 as your structural backbone. Make every control decision using FAIR thinking.<\/strong><\/p>\n\n\n\n

NIST CSF 2.0, updated in 2024, gives you six functions \u2014 Govern, Identify, Protect, Detect, Respond, and Recover \u2014 that provide a complete map of what a security programme needs to address. It is not prescriptive about how. That flexibility is its greatest strength for an engineering leader building a programme without a security team: you can implement CSF at the depth your organisation can currently sustain and mature it over time without rebuilding the structure.<\/p>\n\n\n\n

The reason I add FAIR (Factor Analysis of Information Risk) is that CSF alone does not help you prioritise. When you have fifteen identified risks and budget for controls addressing three of them, you need a principled way to choose. FAIR asks two questions about every risk: how often is this likely to happen, and what is the probable magnitude of loss if it does?<\/p>\n\n\n\n

A concrete example of FAIR thinking applied to any engineering organisation: consider an internal API that processes high-value business logic \u2014 a pricing engine, a claims adjudication service, a transaction authorisation system, or any other core business function \u2014 callable from multiple microservices using a shared API key stored in application configuration. The FAIR analysis: how frequently might an attacker who has compromised one of those microservices try to abuse this API? Given the financial or reputational value of manipulating the business logic it controls, the answer is: with high frequency and immediate intent. The magnitude of loss \u2014 regulatory, financial, and reputational \u2014 is severe. That analysis moves API authentication hardening to the top of the control priority list ahead of findings that might score higher on a generic vulnerability severity scale.<\/p>\n\n\n\n

The compliance trap<\/strong> operates in both directions. Teams that implement controls by checkbox pass their audit while leaving genuine exposure in place. Teams that refuse to implement any control until they have completed a six-month risk assessment defer obvious hygiene in the name of process. Neither is right.<\/p>\n\n\n\n

The pragmatic position: start implementing foundational controls that almost every risk analysis will validate as necessary \u2014 MFA, access control, vulnerability management, incident response \u2014 while building your risk framework in parallel. Do not wait for perfect analysis before doing obviously necessary things.<\/p>\n\n\n\n

The one-page risk register<\/strong> that actually gets used has five columns: the risk description in plain language, the likelihood assessment with a one-sentence rationale, the potential business impact in terms your leadership will understand, the current control status, and the next action with an owner and a date. It is reviewed in your quarterly engineering leadership meeting. It drives sprint planning decisions. That is how risk management becomes real.<\/p>\n\n\n\n

\n\n\n\n

Section 4: The Non-Negotiables \u2014 Policy, Vulnerability Management, and Incident Response<\/h2>\n\n\n\n

Before you build anything sophisticated, three foundations must exist. Without them, every other control is a layer built on sand.<\/p>\n\n\n\n

Policy: Three Documents That Matter<\/h3>\n\n\n\n

Most organisations have too many policies and not enough practice. In year one, three policies are genuinely non-negotiable.<\/p>\n\n\n\n

The Acceptable Use Policy<\/strong> defines what employees and contractors can and cannot do with company systems, data, and networks. Three pages maximum, plain English, signed by everyone with system access. Its purpose is not legal coverage \u2014 it is setting the cultural baseline that security is everyone’s responsibility.<\/p>\n\n\n\n

The Information Classification Policy<\/strong> defines your data categories and minimum handling requirements for each. In most engineering organisations this means four levels: public, internal, confidential (regulated customer data and PII), and restricted (credentials, cryptographic material, audit logs). Every data handling decision in your engineering teams should reference this policy.<\/p>\n\n\n\n

The Incident Response Policy<\/strong> defines who does what when something goes wrong. It names roles \u2014 Incident Commander, Communications Lead, Technical Lead \u2014 establishes escalation criteria, and specifies notification obligations. In an India\/US dual-jurisdiction environment, this must explicitly include your Indian regulatory notification timelines alongside any US-side obligations from your parent company’s compliance framework. The specific timelines vary by sector and regulator \u2014 but they need to be explicitly named before an incident, not looked up during one.<\/p>\n\n\n\n

A policy is real when it changes behaviour on a normal Tuesday, not just during an audit week.<\/p>\n\n\n\n

Vulnerability Management in a Cloud-Native Stack<\/h3>\n\n\n\n

Traditional vulnerability management tools were designed for stable servers with known IP addresses and operating systems that changed quarterly. In a Kubernetes environment, that world does not exist. Containers are rebuilt daily. Images from public registries arrive with hundreds of inherited vulnerabilities. The cluster API server, etcd, and node kubelets each carry their own exposure profile.<\/p>\n\n\n\n

Your vulnerability management programme needs three layers:<\/p>\n\n\n\n

Image scanning in CI\/CD<\/strong> \u2014 every container image must be scanned before it reaches production. Trivy, integrated as a required CI\/CD gate, is the recommended starting point: fast, accurate, and free. The gate should fail builds with CRITICAL severity CVEs that have an available fix, and generate a report for HIGH severity findings requiring review within five business days.<\/p>\n\n\n\n

Cluster-level scanning<\/strong> \u2014 kube-bench runs the CIS Kubernetes Benchmark against your cluster configuration and reports which controls are passing and failing. Run it monthly and track the score trend. A rising score means your hardening programme is working.<\/p>\n\n\n\n

CVE SLA by severity<\/strong> \u2014 define and publish your response commitments: CRITICAL with an available fix within 72 hours, HIGH within 14 days, MEDIUM within 60 days. The number of CVEs violating SLA is a metric your leadership can track and hold engineering accountable to.<\/p>\n\n\n\n

In 2026, your vulnerability surface also includes AI dependencies \u2014 the Python packages powering your LLM pipelines, the npm packages in your MCP servers, the model serving frameworks. Include them in your scanning scope now.<\/p>\n\n\n\n

Incident Response: The Thirty-Minute Tabletop<\/h3>\n\n\n\n

The most common failure in incident response is not having a bad plan. It is having a plan that nobody has ever practised.<\/p>\n\n\n\n

The antidote is a quarterly thirty-minute tabletop exercise with your engineering leads. Start with a compromised service account token \u2014 the most common initial access vector in Kubernetes environments. Walk through: how did we detect it, who makes the isolation decision, who preserves forensic evidence before pod termination, who notifies leadership and when, who drafts the communication to the affected business unit.<\/p>\n\n\n\n

The first time you run this exercise, you will discover that your alert routing goes to an inbox nobody monitors outside business hours. You will discover that your isolation runbook assumes access that three of the four relevant people do not have. These are valuable discoveries. They are far more valuable to make in a tabletop than during an actual breach at 2 AM.<\/p>\n\n\n\n

For AI-era incidents, extend the playbook: add a prompt injection scenario where an attacker induces an LLM endpoint to behave unexpectedly or exfiltrate data. The additional response steps include isolating the inference endpoint, rolling the compromised session context, reviewing RAG pipeline access logs, and determining whether any retrieved data constitutes a reportable breach under your applicable regulatory framework.<\/p>\n\n\n\n

\n\n\n\n

Section 5: Securing the Modern Stack<\/h2>\n\n\n\n

With foundations in place, the technical control layer becomes tractable.<\/p>\n\n\n\n

Endpoints: Three Categories<\/h3>\n\n\n\n

Developer laptops require EDR, full-disk encryption, and MDM enrolment. The consistent gap is offboarding: when an engineer leaves or moves teams, credentials cached on their device \u2014 SSH keys, cloud provider profiles, cluster contexts \u2014 need active revocation, not passive expiry.<\/p>\n\n\n\n

Cloud workstations \u2014 where developers run their environments inside cloud-hosted VMs or containers \u2014 are endpoints with production system access. Apply the same controls: network segmentation, access logging, ephemeral credential issuance.<\/p>\n\n\n\n

Kubernetes nodes are the category no pre-2023 security guide covers adequately. A worker node is an endpoint in every meaningful sense \u2014 it runs workloads, holds credentials, and has a kernel exploitable to escape container boundaries. Node hardening (AppArmor profiles, Seccomp policies, CIS node benchmark compliance) is endpoint security for cloud-native infrastructure.<\/p>\n\n\n\n

Network: Default-Deny and East-West Control<\/h3>\n\n\n\n

The default Kubernetes network model allows every pod to communicate with every other pod across every namespace. In any environment processing regulated or sensitive data, this is an untenable starting point. Lateral movement through a flat pod network is how a compromised low-privilege container becomes a full cluster compromise.<\/p>\n\n\n\n

Default-deny NetworkPolicy as the cluster-wide baseline \u2014 no pod-to-pod communication unless explicitly permitted. Implement namespace by namespace, starting with namespaces that process your most sensitive data. Use Cilium as your CNI for L7-aware policy enforcement and Hubble observability. For cross-cluster and cross-geography connectivity, implement mutual TLS and verify service identity at the application layer.<\/p>\n\n\n\n

AI Workload Security: The 2026 Addition<\/h3>\n\n\n\n

LLM inference endpoints are network-accessible services with an unusual attack profile: their behaviour can be manipulated by crafted inputs, they may be induced to return data from their context or retrieval pipeline that they should not, and they are often connected to internal tools through agentic frameworks that dramatically extend their blast radius.<\/p>\n\n\n\n

The four controls that matter most: network isolation (dedicated namespaces, strict egress NetworkPolicy), authentication on every AI endpoint (no unauthenticated MCP servers inside your network), input and output logging for every LLM request and response, and dependency scanning for AI stacks.<\/p>\n\n\n\n

\n\n\n\n

Section 6: People Are the Programme<\/h2>\n\n\n\n

Every significant security incident I have investigated across my career had a human factor in its root cause. Not human error in the naive sense \u2014 not someone clicking a phishing link because they were careless. Human factor in the systemic sense: access rights too broad because the approval process was too slow, a service account with production database access because removing it would require a deployment, a developer who knew a configuration was wrong but did not know who to tell.<\/p>\n\n\n\n

If you cannot name a specific human being who is responsible for justifying a service account’s current permissions at any given moment, that service account has too much access.<\/strong> Apply this test to your entire service account inventory. The number of accounts that fail it will surprise you.<\/p>\n\n\n\n

The Security Champion Model<\/h3>\n\n\n\n

A dedicated security team is a luxury that most GICs and GCCs do not have in their early security programme years. The security champion model is the highest-leverage substitute: one engineer per squad, formally responsible for owning the threat model for their services, triaging CVE findings, and being the first point of contact for security questions. Supported by a monthly champion community of practice and direct escalation access to you.<\/p>\n\n\n\n

In an engineering organisation with squads distributed across India and the US, the champion model is the only scalable approach to embedding security culture without hiring a dedicated team.<\/p>\n\n\n\n

Training That Changes Behaviour<\/h3>\n\n\n\n

Quarterly phishing simulations with immediate micro-coaching at the moment of failure \u2014 not a shame message, a two-minute lesson on what the simulation was testing. Two-minute security moments in weekly engineering all-hands. CVE remediation visible in sprint metrics alongside delivery work. These three practices, sustained, build a security culture that scales.<\/p>\n\n\n\n

\n\n\n\n

Section 7: Measuring What Matters<\/h2>\n\n\n\n

The five metrics worth tracking \u2014 and how to communicate them to two different audiences simultaneously:<\/p>\n\n\n\n

Mean Time to Detect (MTTD)<\/strong> \u2014 time from compromise initiation to first alert. To engineering leadership: measures whether your detection infrastructure is working. To a board or US parent company: “We would identify a production compromise within X minutes, compared to an industry median measured in weeks.”<\/p>\n\n\n\n

Mean Time to Remediate (MTTR) by severity<\/strong> \u2014 time from detection to resolution for CRITICAL, HIGH, and MEDIUM findings. Tracked against your published SLA commitments. Trending upward means either your team is overwhelmed or your remediation process is broken.<\/p>\n\n\n\n

Open HIGH\/CRITICAL CVE count by age<\/strong> \u2014 the age distribution is more informative than the raw count. Ten CVEs all under seven days old is a healthy programme under normal load. Ten CVEs averaging forty days old is a programme failing its SLA.<\/p>\n\n\n\n

Percentage of production services with a documented threat model<\/strong> \u2014 a maturity indicator and a leading indicator of incident frequency. In any engineering organisation, the goal is 100% coverage for services processing regulated or sensitive data.<\/p>\n\n\n\n

Percentage of production deployments with signed container images<\/strong> \u2014 a concrete, automatable supply chain security metric that moves toward 100% as you implement image signing and admission enforcement.<\/p>\n\n\n\n

The Three-Year Horizon<\/h3>\n\n\n\n

Year one is foundation:<\/strong> asset inventory, data classification, three essential policies, vulnerability management in CI\/CD, IR plan and first tabletop, MFA everywhere, security champion in every squad. At year-end: you know what you have, you know your obligations, and you have a practised response when something goes wrong.<\/p>\n\n\n\n

Year two is hardening:<\/strong> Kubernetes security controls, supply chain security (SBOM, image signing, policy enforcement), Zero Trust for cross-geography connectivity, SIEM integration for log correlation and alerting. At year-end: your attack surface is substantially smaller and your detection capability is real.<\/p>\n\n\n\n

Year three is culture and automation:<\/strong> security gates in every deployment pipeline, continuous contextual developer training, threat modelling as a standard part of service design, automated compliance evidence collection. At year-end: security is not a separate programme the engineering team supports. It is part of how the engineering team works.<\/p>\n\n\n\n

\n\n\n\n

Closing<\/h2>\n\n\n\n

The conversation described at the beginning of this article \u2014 the one where you are handed security ownership unexpectedly \u2014 does not have to be a crisis. It can be the beginning of one of the most intellectually engaging chapters of an engineering leadership career.<\/p>\n\n\n\n

Security is not a destination you reach. It is a discipline you maintain, a set of practices you embed, and a culture you cultivate. The organisations that do it well are not the ones with the largest security budgets or the most sophisticated tools. They are the ones where every engineer understands that security is part of their job, where incidents are learning opportunities rather than blame events, and where the security posture of the organisation is a visible, measured, continuously improving conversation at every level of leadership.<\/p>\n\n\n\n

Start with what can actually hurt you in ninety days. Know what you are protecting. Make risk-informed decisions. Build the non-negotiables before the sophisticated. Invest in your people. Measure what matters and communicate it clearly.<\/p>\n\n\n\n

The programme builds itself from there.<\/p>\n","protected":false},"excerpt":{"rendered":"

You have been handed security ownership alongside delivery. Here is where to start \u2014 and what the generic frameworks will not tell you. By Shashijeevan M. P. \u2014 VP of Delivery | CEH | M.Tech, IIT Kharagpur | thehackerbuild.com There is a moment that many engineering leaders recognise immediately when they hear it described. You […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-22","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"blocksy_meta":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t