Security is often discussed as a feature that can be scheduled after a product has proved itself. That approach creates avoidable risk and usually increases cost.
The most affordable time to make a secure decision is while the system is being designed. The most expensive time is after customers, data and commercial commitments depend on it.
Security by default does not mean turning every project into a lengthy compliance programme. It means making sensible choices early, recording them clearly and increasing controls as the product and its risks grow.
Start with the data
A team cannot protect information it does not understand.
Before choosing controls, identify what the product collects, why it is needed, where it is stored and who should have access. This should include customer data, operational logs, analytics, backups and information shared with third parties.
Data minimisation is one of the most effective security measures. Information that is not collected cannot be leaked, mishandled or requested during an incident. If a field has no clear purpose, it should not be stored by default.
Retention also matters. Keeping data indefinitely creates responsibility without necessarily creating value. A practical retention policy should explain when information is removed and how that process is verified.
Design identity and access deliberately
Access control should reflect responsibility. Users, services and administrators should receive the minimum access required for their role.
This principle applies to cloud permissions, database credentials, internal tools and customer-facing features. Shared administrator accounts and broadly scoped service credentials may feel convenient early on, but they make incidents harder to contain and actions harder to audit.
Strong defaults include:
- individual accounts for privileged access
- multi-factor authentication
- role-based permissions
- short-lived credentials where possible
- regular access reviews
- prompt removal of access when responsibilities change
These controls support both security and operational clarity.
Treat every input as untrusted
Applications receive data from forms, APIs, files, webhooks and third-party services. Every boundary should validate what it accepts.
Validation should cover type, length, format and expected values. Rate limits should protect expensive or sensitive operations. File uploads need explicit size and content restrictions. Errors should be useful to the user without exposing internal details.
These are basic controls, but they prevent a wide range of common failures.
Make dependencies part of the system
Modern software relies on open-source packages, cloud services and external APIs. Their risk belongs to the product, even when their code is maintained elsewhere.
Teams should know which dependencies are critical, keep them updated and monitor published vulnerabilities. New packages should be added for a clear reason, not simply because they make a small task more convenient.
Third-party services also need review. Consider what data they receive, how they authenticate requests, what happens during an outage and how the product behaves if the service changes.
Build useful audit trails
Logs are valuable when they help answer practical questions.
For security and operations, a team should be able to determine who performed a sensitive action, what changed, when it happened and whether it succeeded. Authentication failures, permission changes, administrative actions and unusual request patterns often deserve specific attention.
Logs should not become an uncontrolled copy of sensitive data. Record enough context to investigate events, but avoid writing secrets, credentials or unnecessary personal information.
Plan for failure before it occurs
Every system will experience failures. A responsible team decides in advance how to detect, contain and recover from them.
At a minimum, the team should know:
- who owns incident response
- how urgent issues are reported
- which systems and data are most critical
- how credentials can be revoked
- how backups are restored and tested
- how customers will be informed when appropriate
A short, rehearsed plan is more valuable than a comprehensive document nobody can use under pressure.
Scale controls with evidence
Security work should reflect the product's stage, data and customer commitments.
An early prototype using synthetic data does not need the same controls as a production platform handling sensitive customer information. The mistake is not starting small. The mistake is allowing temporary shortcuts to become permanent without review.
Define the point at which additional controls are required. A new enterprise customer, a new category of personal data or a move into a regulated market may all trigger a more formal assessment.
Security supports delivery
Good security enables a team to move with confidence. Clear access, reliable logs, controlled dependencies and tested recovery reduce the chance that growth will expose weak foundations.
Customers increasingly assess security before they adopt a product. Teams that build it into their decisions can answer those questions with evidence and avoid late changes that delay sales.
A secure product is not a product that never changes. It is a product that can continue changing without losing control of its data, systems or customer trust.
For the delivery decisions that put these principles into practice, see my approach to technology transformation and platform delivery. Where agents can take action, the Agentic AI reading path explores the additional boundaries around tools, approvals and operational control.