Security is often treated as something specialists add at the end. In practice most incidents trace back to a few plain weaknesses, and most of those are settled by decisions made at the start.

Where problems usually come from

  • Stolen or guessed passwords.
  • Software and libraries left without updates.
  • Staff accounts with more access than the job needs.
  • Keys and passwords stored in the code or shared in chat.
  • Input from users that is trusted without being checked.
  • Backups that do not exist or cannot be restored.

Logins and access

  • Two-step sign-in for staff and administrators.
  • Sign-in through the company's existing accounts where possible.
  • Roles, so each person sees only what the job needs.
  • Access removed on the day someone leaves.
  • Passwords stored in a form that cannot be read back.
  • A limit on repeated sign-in attempts.

Data

Data should be encrypted on its way across the network and where it is stored. Collect only what the product needs, and decide how long to keep it.

Know which country the data is stored in. Data protection laws, such as GDPR in Europe and the PDPL in Saudi Arabia, set rules about personal data and where it may go.

Do not handle card numbers yourself. A payment provider takes them directly, and your system keeps only a reference.

What to ask of the build

  • Every change reviewed by a second developer.
  • Libraries checked for known vulnerabilities and kept up to date.
  • Separate test and live environments, with no real customer data in testing.
  • Keys and passwords held in a proper secrets store.
  • Checks against the common web weaknesses listed by OWASP.
  • An independent penetration test before launch, for anything holding sensitive data.

After launch

Updates applied on a schedule. A record of who did what in the system. Alerts for unusual activity. Backups that have been restored in a test.

If something goes wrong

Write a one-page plan: who is told first, who can take the system offline, who speaks to customers, and when a regulator has to be informed. Many data protection laws set a deadline for reporting a breach, so find out which apply to you before you need to know.

Questions for a supplier

  • How do you handle logins and staff access?
  • How are libraries kept up to date?
  • Where is the data stored, and who can reach it?
  • What is tested before each release?
  • If there is an incident, what happens and who calls whom?

Clear answers matter more than long ones.

Our service

Custom Software Development