Secure internal software: the decisions that matter.

Internal tools accumulate the most sensitive data in a business - customer records, pricing, contracts, payroll, supplier terms - while receiving the least security attention, because they are behind a login and nobody outside is supposed to see them. That reasoning has two holes: most incidents involve credentials that were legitimately issued, and 'internal' systems are routinely opened to contractors, clients, and partners once they exist.

The practical consequence is that an internal tool should be designed as though it will eventually be accessed by more people, in more roles, than the first version anticipates. That is a design posture, not a budget line, and it costs very little if adopted early.

Almost every meaningful control in a business system depends on knowing who is acting and what they are allowed to do. Get this wrong at the start and everything built on top inherits the problem.

Model permissions as roles rather than individuals, so that joiners, leavers, and cover do not require re-deriving who can do what. Grant the narrowest set that lets each role do its job. Separate the ability to perform an action from the ability to approve it, wherever the approval is the control.

Enforce authorisation on the server, on every request, for every object. Interface-level restrictions are a usability feature, not a security one: hiding a button does not stop a request. The most common serious flaw in internal software is an endpoint that checks whether someone is logged in but not whether this particular user is entitled to this particular record.

Use a single identity provider rather than a separate password per tool, so that removing someone's access actually removes it everywhere, and make offboarding a defined procedure rather than a memory exercise.

API keys, database credentials, and tokens belong in a managed secret store, injected at runtime - never in source control, never in a shared document, never pasted into a chat. They should be rotatable without a code change, and rotation should be exercised occasionally rather than assumed to work.

Integrations deserve specific attention because they are where privilege quietly escalates. A service account created for one integration tends to accumulate scopes over time until it can do everything. Give each integration its own credential, scoped to exactly what it needs, and review those scopes periodically. When an integration is retired, revoke its credential rather than leaving it dormant.

For data, decide three things explicitly and write them down: what is collected, where it is stored and processed, and how long it is kept. Retention is the one most often skipped, and unbounded retention converts every future incident into a larger one. Personal data handling in the UAE is governed by federal legislation and, for some entities, free-zone specific rules - confirm what applies to you with your own advisers rather than assuming a default.

There are two kinds of logging and systems need both. Application logs exist to debug behaviour. Audit logs exist to answer, months later, who did what to which record and when. They have different retention, different access, and different immutability requirements, and conflating them means the audit questions cannot be answered.

An audit log should be append-only, should record actor, action, target, timestamp, and the before-and-after state where a record changed, and should be readable by the people who need to investigate without granting them the ability to alter it. It should also capture authentication events, permission changes, and exports - the last is frequently omitted, and bulk export is exactly the action worth being able to review.

Logs that nobody looks at have limited value, so pair them with alerting on a small number of high-signal events: repeated authentication failures, permission escalations, unusual export volume, and access to sensitive records outside normal patterns.

Security is a state a system is in, not a phase it passed through, and most of the work after launch is unglamorous and scheduled.

Dependencies need updating on a cadence, because the majority of practical vulnerability exposure in modern applications arrives through them. Automated dependency alerts plus a regular review window handles this without heroics. Backups need testing by restoring them somewhere; an untested backup is a belief, not a control. Environments should be separated so that development and testing never touch production data, and production access should be limited and logged.

Deployment should be repeatable from a documented procedure, so that recovery does not depend on one person's memory. And a system that has been running for two years should get an independent review of its access model, dependencies, and data handling - the shape of a business changes, permissions widen, and integrations accumulate, all without anything visibly breaking.