Security is an engineering habit

Revisited from the Foresaw archive. The argument and structure have been updated for this edition.

A security review is useful, but it cannot compensate for a system whose everyday engineering decisions have no clear owner. Security needs to be part of how information is accessed, software is changed, and failures are handled.

A practical starting point is to understand the system and make its boundaries visible.

Know what needs protection

Identify important information, critical workflows, and the dependencies that support them. Record where data moves and which people or services can access it.

That map makes design discussions more specific. It also helps reveal components that have fallen outside normal maintenance and ownership.

Keep access intentional

Give each person and service the access required for its work. Make changes in responsibility visible in the access process, including when a person leaves or a service is retired.

Treat credentials and configuration as part of the operational design. Know who can rotate them and how dependent systems recover from that change.

Build for detection and recovery

Logging should help a responsible team understand meaningful events. Decide which signals require action and protect the information recorded in the logs themselves.

Recovery also needs practice. Verify that essential data and services can be restored under realistic conditions rather than assuming a stored backup completes the job.

Make the work continuous

Changes in software, infrastructure, and business process can change the risk. Bring security questions into design and delivery conversations early. A shared routine with clear accountability is more useful than a policy that nobody can connect to the system in front of them.