The incident was the warning.
The real risk was six months ahead.

The sole Business Analyst embedded inside a five-person product and engineering team at a cybersecurity research firm whose client base included defence-sector organisations and former military personnel. The team was building a commercial vulnerability intelligence platform while simultaneously delivering bespoke threat intelligence solutions to existing clients.

The team was operating without a dedicated security manager, without formal SDLC security processes, and under significant delivery pressure. Everyone — including non-technical stakeholders — had admin privileges on the Azure Databricks production workspace. The data pipeline and web application environments were the operational backbone of everything being built and delivered.

Six months from the point of the incident, there was a planned organisational scale on the roadmap — more team members, a commercial product release, and a growing client base in regulated sectors. The conditions were set for a material security failure. What was missing was someone to see it before it happened.

On a Friday afternoon, a routine data transformation was underway in Azure Databricks — ingesting the MITRE ATT&CK TAXII dataset as part of building the threat intelligence pipeline. When attempting to mount Azure Blob Storage directly onto a notebook to begin the silver layer transformation, the shared production pipelines were accidentally disrupted.

Pipeline failure emails started arriving immediately. The data architect was escalated on Slack, a call was made, screen shared, and the sequence walked through. He rolled back the change within the hour. No client data was affected. Blast radius contained.

The incident itself was not catastrophic. What it exposed was. Without environment separation, any team member — at any privilege level — could disrupt production at any time. As the team scaled, that risk would not stay linear. It would compound.

Three categories of systemic risk were identified across both environments that needed to be addressed before the scaling milestone:

Rather than raising everything at once and overwhelming a team already under pressure, a deliberate prioritisation decision was made. The full picture was documented — five material risks across two environments — and recommendations were sequenced around what was most critical to address before the scaling milestone.

The three most urgent issues — no sandbox environment, no least privilege enforcement, and hardcoded credentials — were raised first. Separate conversations were had with the data architect and the product manager, explaining the risks in business terms, connecting them to the scaling timeline, and proposing that remediation be embedded directly into the sprint backlog.

Risk statements follow the threat-vulnerability-consequence format aligned with ISO 27005 and NIST SP 800-30. Inherent ratings reflect the state of the environment before any controls were implemented. Each risk maps directly to the controls that treat it.

Controls were structured across the access, application, data, and governance layers — ensuring the risk surface was addressed systematically. The balance skews preventive, reflecting the pre-scale nature of the work. Detective and governance controls were layered in to sustain the controls over time rather than treating remediation as a one-off exercise.

This work was self-directed, delivered without a senior security mentor, and built proportionately for a team of five under delivery pressure. The following is an honest assessment of the gaps and what a more mature organisation would do differently — alongside a distillation of how the work was driven without formal authority.