Security is a design property. The architecture either supports a secure system or it does not. Adding security to an insecure architecture after the fact is expensive, incomplete, and unreliable.
Most security incidents are not the result of sophisticated attacks against well-defended systems. They are the result of known vulnerabilities in inadequately governed ones. Credentials that were not rotated. Access controls that were not maintained. Patches that were not applied. Data that was accessible to people who had no business reason to access it.
This is a governance problem, not a technology problem.
What security governance covers
Access controls. Who can access what, under what conditions, with what audit trail. Access controls that were designed in, rather than added retrospectively, are more likely to be comprehensive and maintained.
Infrastructure security. The security posture of the systems and environments that host the data and applications. Patch management, configuration management, and the operational processes that keep the posture current.
Data security. How sensitive data is stored, transmitted, and accessed. Encryption at rest and in transit. Data minimisation — holding only what is needed for the purpose for which it is held.
Incident detection and response. The ability to detect anomalous activity and respond to it. Monitoring that is operational — not configured and forgotten.
Third-party security. The security posture of the vendors, platforms, and services that have access to the organisation’s data or systems. The organisation’s security is not stronger than its weakest dependency.
The approach
Security standards are part of the tested framework applied to every engagement at Sixteen Pillars. Not adapted per project. Applied consistently, starting with the data model.
Start a Conversation