Skip to content

Infrastructure & Integrations

Security foundations: built in as the system is made, not checked at the end

Most attacks on small business software aren't clever. A form gets flooded. Someone changes a number in the address bar to see another customer's invoice. A key gets pasted into code, or an old package has a known flaw. Each has a well-known defence, and the defence costs little when it's built in from the first day. We build that baseline into every system, and every attempt it stops is recorded.
Talk through your baselineSee the baseline ↓
attemptcontrol already thereaudit recordbooking form sent 300 timesin one minute, from one addresslimit on public formslimit on public formsslowed after 10 a minutestopped10:14 rate.limitedINV-2301 changed to INV-2302in the address bar, by a customerpermission checkpermission checkonly your own invoicesstopped10:21 access.denieda script typed into a messagein the customer contact forminputs checkedinputs checkedstored as text, never runstopped11:03 input.escapedpackage with a known flawused by the booking pagepackage checkpackage checkrelease blocked until updatedstopped11:40 release.blockeda key pasted into codein a proposed changesecret scansecret scanchange refused · key replacedstopped12:15 secret.found

The baseline, in every system

Not extras. Each one ships with the first release.

  1. 01

    Least access

    People and systems get only what their work needs

    A technician can't see billing; the accounting export can only read.

  2. 02

    Secrets out of the code

    In a vault, per environment

    Passwords and keys are never in the code, and a scan refuses any change that contains one.

  3. 03

    Inputs checked

    Everything from outside is untrusted

    Forms, uploads, notices from other systems and AI output are checked against what's expected before they're used.

  4. 04

    Permissions on the server

    Not hidden buttons

    Every request checked for who's asking and what they may see, including in the database itself.

  5. 05

    Packages watched

    Known flaws block the release

    Every package the software uses is checked on each change and each week.

  6. 06

    Limits on public forms

    Flooding slowed, not served

    Booking, contact and sign-in forms slow down repeated attempts from the same place.

  7. 07

    An audit record

    Who did what, and what was stopped

    Sign-ins, permission changes, risky actions and blocked attempts, kept where they can't be edited.

  8. 08

    Environments kept apart

    Test never touches live

    Preview and staging use their own data and keys, so a mistake in testing can't reach a customer.

When each check runs

Security that depends on someone remembering doesn't happen. These run on their own.
Secret scanevery proposed changethe developer; the change is refused
Package checkevery change, and weeklythe lead developer; releases blocked
Permission testsevery changethe developer; release blocked if one fails
Access reviewevery quarteryou and the lead developer: who still needs what
Restore testevery quarteryou: a backup restored and checked

A flaw announced in a package we use

Flaws in widely used packages are announced every week. What matters is how quickly you know and act.

Flaw announced in a date-handling package

  1. Found

    the weekly package check flags it the same morning

    done

  2. Assessed

    used by the booking page; the flawed feature is not

    done

  3. Updated

    to the fixed version anyway; tests pass

    done

  4. Released

    through the usual path, same day

    done

  5. Recorded

    what was found, what was used, what changed

    done

Fixed the day it was announced, with a record of why it was safe in the meantime.

Where the baseline applies

In

People
forms, sign-ins, requests
Other systems
notices and calls
Code changes
every proposed change
Baseline
checked, limited, recorded

Out

Allowed actions
only what's permitted
Refused attempts
and blocked changes
Audit record
who, what, when

Part of every system we build

It isn't a separate service. It's also not a substitute for specialist security work.

What we do

  • Build this baseline into every system, from the first release.
  • Bring existing software up to that baseline, one gap at a time.
  • Work alongside your security specialists and fix what they find.

What we don't do

  • Security audits, penetration tests or certifications. Those need a specialist firm.
  • Monitoring for attacks around the clock, or responding to a breach in progress.

Where this capability is used

Next to security foundations

Questions about security foundations

Will our software be secure?

No one can honestly promise that. We can promise this baseline is built in and checked on every change, which stops the common attacks on small business software and records what it stops.

Are you a security consultancy?

No. We build software with a solid baseline. If you need an audit, a penetration test or a certification, a specialist firm does that, and we fix what they find.

Can you check our existing software?

We can review it against the same baseline and list the gaps in order of risk. That's a list of what to fix, not a formal audit.

What about payment card details?

We don't store them. Payments go through a payment provider, so card details never touch your systems.