Data Security for Enterprise Software Projects

Security is usually treated as a phase — something checked at the end, before launch, by someone other than the people who built the system. This guide is about why that sequencing is backwards, and what building security in from the start actually involves.

What a breach actually costs

IBM's Cost of a Data Breach research puts the global average cost of a breach at $4.99 million. (IBM) This is an average across industries and breach types — any specific organisation's exposure depends heavily on data sensitivity, regulatory jurisdiction and breach scale — but it establishes that security is a line item with a real, quantifiable financial consequence, not an abstract risk.

The US Government Accountability Office's review of the federal government's oldest legacy systems found seven of eleven most-critical systems already carry known cybersecurity vulnerabilities. (GAO-25-107795) That figure describes systems that were not built with security as a design constraint, because the security landscape they were built for no longer exists.

Third-party risk is not a secondary concern

A meaningful and rising share of breaches originate through a vendor, contractor or supply chain relationship rather than a direct attack on the organisation itself. This makes vendor security due diligence a direct extension of your own security posture, not a separate compliance exercise — your security genuinely is your suppliers' security, a point we cover in more depth in a companion piece on third-party risk.

What compliance certifications actually prove — and don't

SOC 2 is a widely referenced framework, but it is worth being precise about what it actually is: an attestation report produced under American Institute of CPAs (AICPA) standards, evaluating a service organisation's controls against defined Trust Services Criteria — not a "certification" in the way ISO standards use that term, despite frequently being marketed as one. We cover exactly what a SOC 2 report does and doesn't demonstrate in a dedicated piece.

ISO/IEC 42001, published in December 2023, is the first international standard specifically for AI management systems, addressing governance, risk management and lifecycle controls for organisations developing or deploying AI. Its existence signals that AI-specific governance is being formalised as its own discipline, separate from general information security management.

Building security in from the start: what it actually means

Data minimisation as a default, not an afterthought. Collect what the system genuinely needs, not what might be useful someday. Every field of stored personal data is a liability that did not need to exist if the system did not need it.

Audit trails designed into the architecture, not retrofitted. A system that logs who accessed what, when, and why from day one produces an audit trail as a byproduct of normal operation. A system that has to be instrumented after the fact, under deadline pressure, produces gaps exactly where they matter most. We cover this in detail for AI systems specifically in a companion piece.

Vendor and sub-processor mapping before selection, not after a breach. Know where your data actually goes — which cloud provider, which AI model provider, which analytics tool — before you commit to a vendor, not when a customer or regulator asks and you have to find out. Our piece on what to ask any AI vendor about your data covers the specific questions worth asking.

Compliance as a map across jurisdictions, not a single checklist. An organisation operating across the EU, UK, US and India is subject to GDPR, the UK's regime, the emerging AI Act obligations, and India's DPDP Rules simultaneously, each with different definitions and different triggers. We map these against each other in a dedicated piece.

Why the sequencing matters economically, not just technically

Retrofitting security into a system already in production is measurably more expensive and less complete than designing it in from the start, for the same reason retrofitting any other architectural property is — the assumptions embedded early are the hardest and most expensive to unwind later. This is not a moral argument about doing things properly. It is the same economic logic that applies to technical debt generally: deferred cost compounds, and security debt compounds in a currency — breach risk — that can arrive all at once rather than gradually.

What we do

We treat security architecture as a design phase alongside the functional requirements, not a review that happens after the functional design is locked. If you are scoping a project that will handle sensitive data and want security built in from the first design conversation rather than audited in afterward, that is a conversation we are glad to have.

Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source.