Internal tool development services

Core controls

Least privilege in practice

It is tempting to give every internal user full access so nobody is blocked. The result is that anyone can issue refunds, delete records or export customer lists. A better pattern is a few clear roles, such as support, operations, finance and administrator, each with only the actions it needs. Rare high-risk actions can need a second person's approval or be limited to a small group.

Review role assignments regularly, because access tends to accumulate as people change jobs.

Managing staff access over time

Audit logs people can use

An audit log is only useful if someone can read it. Record who made each change, when, what the previous and new values were and, for significant actions, why. Make the log searchable by record and by person, so questions such as 'who changed this customer's address?' can be answered in seconds. Protect the log itself from being edited.

Protecting customer data

• Show only what is needed

  Mask full card or identity details where staff do not need them.

• Limit exports

  Restrict bulk downloads to those with a clear need.

• Retention

  Remove personal data when no longer needed, as the ICO requires.

• Secure hosting

  Keep internal tools off the public internet where practical, or behind strong sign-in.

Designing access for a new tool

1. 01

   List actions

   Every action the tool will allow.

   Output: Action list

2. 02

   Define roles

   Which roles need which actions.

   Output: Permission matrix

3. 03

   Mark high-risk actions

   Refunds, deletions, exports and bulk changes.

   Output: Extra safeguards

4. 04

   Test access

   Each role checked against the matrix.

   Output: Verified controls

Bulk actions with safeguards

Bulk actions, such as updating prices or closing many records, save time but can do a lot of damage quickly. Show a preview of exactly what will change, require confirmation, limit the number of records per action and keep a way to reverse the change. Logging the whole batch as one entry, with its list of affected records, makes later checks straightforward.

Using company sign-in

Connecting internal tools to the sign-in system your organisation already uses, such as its email or identity provider, means staff have one account to manage and access can be removed in one place when someone leaves. It also lets you apply multi-factor authentication consistently. Where that is not possible, the tool's own accounts should still be individual, with strong passwords and multi-factor authentication enabled.

Ask any provider how sign-in will work before building begins.

Testing that permissions hold

Permissions must be enforced on the server, not just by hiding buttons in the interface. Automated tests that try each action as each role, and confirm that unauthorised attempts are refused, catch mistakes before staff do. Repeat these checks whenever new actions are added, because new features are where gaps tend to appear.

When something goes wrong

If a mistaken or unauthorised change happens, the audit log shows what was affected and who made the change. Plan in advance how such incidents are reviewed and how changes can be reversed.