Governance & Security Controls

Access control, audit logging, and data governance are consistently treated as things to add later — after the system is running, after the team has adopted it, and often after an incident or audit finding has made the gap visible. The cost of this sequencing is high: retrofitting governance into a running system is significantly more complex than designing it in from the start, and the window of exposure between deployment and governance implementation creates real risk.

Every system we deploy is designed with governance requirements addressed at the architecture phase. This is not a premium add-on. It is how we define production-ready. A system without documented access controls, functioning audit trails, and a tested backup procedure is not a production system — it is a liability.

Access control design begins with a question that most deployments skip: what roles does this system actually need, and who should hold each role? The answer shapes every subsequent access decision.

We design role structures based on function, not on individual user requests. Read-only roles are defined separately from operator roles, which are defined separately from administrative access. Access is granted to roles, not to individuals, and role assignment is reviewed as part of the onboarding and offboarding process.

For organisations with multiple systems, we implement centralised identity through a federated identity provider. This means that provisioning and deprovisioning happens in one place. When someone joins the organisation, they are added to the identity provider and receive access to every connected system based on their role. When they leave, one action removes their access everywhere.

Credentials are stored in a secrets management system, not passed around in configuration files or chat history. Rotation procedures are defined and documented for every credential class.

An audit trail has two components: the events are logged, and the logs are retained somewhere they can be queried and cannot be tampered with by the subjects of the audit. Both requirements are necessary. Many systems log events to the same system being audited, making the logs vulnerable to deletion or modification by a compromised or rogue administrative account.

We configure audit logging to write to a separate, append-only log store. Retention periods are set based on your compliance posture and contractual requirements. The logs are queryable for access reviews and incident investigations.

Data residency requirements — where data can be stored, who can access it, and under what legal framework — are addressed during the architecture phase, not discovered during a compliance review. If your data processing agreements, client contracts, or regulatory requirements constrain where data can reside or how it can be accessed, those constraints are built into the system design from the start.

A backup that has never been restored is not a backup — it is a file with an unknown probability of being useful in an emergency. Backup verification is the practice of regularly testing that backups can actually be restored to a functional system within an acceptable timeframe.

Every system we deploy has a defined backup schedule, a tested restoration procedure, and a recovery time objective that is validated before the system goes live. Backup completion is monitored. Failed backups generate alerts. Restoration tests are conducted on a schedule and documented.

Disaster recovery planning addresses the scenarios that most organisations prefer not to think about: what happens if the primary hosting environment becomes unavailable, if the primary database is corrupted, or if a ransomware event encrypts production storage. The recovery procedure should be documented, tested, and actionable by someone other than the person who originally set up the system.