Cybersecurity

Security by design: building controls into business applications

If access, audit and data handling are added after the workflow feels finished, they will always feel like friction. They should have been the workflow.

6 min read

Business applications are often secured late. The workflow is designed, the screens are built, and then someone asks who should see which record. Roles are invented under time pressure. Logging is incomplete. Personal data is copied into exports because the product never designed a safer path. Security becomes a gate at the end rather than a property of the system.

Controls are product requirements

Who can raise a request, who can approve it, who can export it, and what is retained afterwards are not compliance extras. They are the rules of the process. When they are designed with the workflow, users experience them as how the system works. When they are added later, users experience them as obstacles and look for ways around them.

Least privilege is an operating decision

Most internal systems fail this test by making too many people administrators. It is faster. It is also how audit trails lose meaning. Role design should follow organisational accountability: the person who does the work, the person who reviews it, the person who governs the system. If those roles cannot be named, the organisation is not ready to put the process into software.

Security by design is not a slogan about encryption. It is the discipline of encoding access, evidence and data protection into the same model as the business process.

This article is a starting point. The page structure is ready for a longer, fully edited version later.

Further reading

Next step

Have a problem worth solving?

Whether you need technology strategy, a data solution, a business application or help transforming an existing process, let's talk.