Your enterprise client hasn't asked about security yet.
They will.

A commercial vulnerability intelligence platform was designed to help security teams move beyond raw vulnerability scores. It ingested CVE data, mapped it to CWEs, MITRE ATT&CK techniques, and CAPEC attack patterns, surfacing contextualised threat intelligence including TTPs and proof-of-exploit data where available.

The platform was developed for a specific audience: red team researchers, SOC analysts, and CISOs at organisations operating in regulated and defence-adjacent sectors. The firm's existing client base included defence-sector organisations and former military personnel, a context that elevated every design decision from standard product practice to a genuine security obligation.

The security controller had a problem with the plan.

The firm had decided to take the platform to market, and the engineering team was already building toward launch. He understood the commercial logic. What he could not get comfortable with was the data itself: TTP intelligence, exploit information, attack path context. Designed for defenders, but usable by attackers. The same product could serve either, depending on who registered.

That concern did not stop the launch. But it started a conversation that shaped everything that followed.

Someone needed to sit between the security controller's hesitancy and the team's delivery pressure and turn the tension into concrete decisions. The developer owned the code and the product manager owned the roadmap, but neither role covered the question of what could go wrong before the first user signed up. The Business Analyst with a background in cyber security was the person who owned that question, and the conversations around registration policy, access design, and data governance existed because it was asked.

Without a deliberate security design process, the product faced three categories of material risk before a single user registered.

The secure by design work was structured across three layers of the product: the access layer (who gets in and how), the data layer (what is collected and how it is protected), and the interaction layer (how the application handles inputs and actions). Each layer had its own workshop, its own stakeholders, and its own set of decisions to work through.

The registration workshop brought together the data engineers and web developer to map out what user data was actually needed. The starting list was long — physical address, company size, purchasing authority. By the end, it had been stripped back to the minimum required for the first version of the product: name, company email, company name, location, and role. GDPR was in the room from the beginning, not added after the fact. The data minimisation decisions were made on a whiteboard before a single field was built.

The access control workshop was a separate piece of work with the web developer. The full user taxonomy was mapped out: security analysts, red teamers, and threat intelligence professionals as normal end users; admin users with defined limits on numbers and privileges; executive users with a deliberate decision made about whether they should carry administrative rights. Edge cases were worked through explicitly. How does a user's privilege get elevated or downgraded? Who can authorise that? How is it logged? Those questions produced both design decisions documented in Figma and Confluence, and formal security requirements written as acceptance criteria in Jira tickets.

The discipline running through both workshops was the same: start with what the team wants, ask what is actually necessary, and design the boundaries deliberately rather than by default.

The first design question was not technical — it was a security policy question: who should be allowed to register at all? This required facilitating a genuine tension between two legitimate perspectives inside the team.

The CTO and engineering team, coming from a research and development background, wanted open registration. Democratising threat intelligence was core to their vision. The security controller, aware of the firm's regulated client base and defence-sector relationships, argued that open access to TTP and proof-of-exploit data posed unacceptable reputational and contractual risk.

The registration form was designed with deliberate data minimisation in mind. Fields captured: first name, last name, company email, company name, location, and role. Phone number was made optional rather than mandatory. Fields proposed for later versions — company size, purchasing authority — were explicitly deferred to avoid collecting unnecessary data in the MVP.

The data layer workshop was driven by two obligations that arrived simultaneously. The sensitivity of the client base made data exposure a reputational and contractual risk. GDPR made it a legal one. Both had to be addressed before the first user registered.

The team had no DPO and no legal adviser. What shaped the decisions was a working knowledge of GDPR Article 5 and a straightforward question applied to every piece of data on the list: do we actually need this?

The answers produced four concrete decisions. Storage in Supabase with encryption at rest. A one-year retention period tied to user activity rather than registration date. Right to erasure implemented in line with GDPR Article 17, so any user could request complete deletion of their data. And a privacy notice drafted and published before the product went live.

What this was not is worth being clear about. A formal Data Protection Impact Assessment, required under GDPR Article 35 for high-risk processing, is a structured document with a specific methodology, typically owned by a DPO and potentially requiring ICO consultation. What the team conducted was a rigorous, good-faith data governance process that covered the right ground for the size and maturity of the organisation. In a larger or more regulated context, this work would be formalised as a DPIA.

Six material risks were identified across the access and data layers through design-phase risk assessment. Risk statements follow the cause-event-consequence format used in ISO 27005 and CRISC methodology.

Controls were categorised as preventive (stopping the risk materialising), detective (identifying when something has gone wrong), or corrective (remedying the situation after the fact). The balance reflects the design-stage nature of the work — preventive controls dominate, with thinner detective and corrective coverage, a known limitation of an MVP built without a dedicated security function.

All 15 security requirements were specified as acceptance criteria in Gherkin syntax in Jira tickets prior to implementation. Testing was completed within approximately one sprint across the sandbox and staging environments.

This work was designed and delivered without a senior security mentor, in an MVP context, by a team without dedicated security expertise. The following reflects an honest assessment of the gaps and what a more mature organisation would do differently.