Financial services IT is usually described as needing better security than other businesses. That framing is not quite right, and it leads to the wrong investments.
The controls are largely the same ones any business should have. What differs is the standard of evidence. In an ordinary business, a control that works is sufficient. In a regulated financial business, a control that works but cannot be demonstrated to have worked is treated as absent.
That single difference reshapes the architecture, because systems designed to function are not automatically systems designed to produce evidence.
Attribution: every action to a person
The foundational requirement is that any action can be traced to an individual afterwards. Not to a role, not to a team, and not to an account three people share.
- One account per person, everywhere, with no exceptions for administrative or service use.
- Administrative access through a named account with elevation, never a shared privileged login.
- Application-level logging that records who did what to which record and when, not only that a record changed.
- Database access by individual credentials where humans access data directly, rather than through a shared application account.
- Third-party and supplier access individually identified and individually revocable.
The third point is the one most often missing in systems that were not designed for it. Many business applications record that a value changed and not who changed it, and retrofitting that is substantially harder than building it in.
Logs that constitute evidence
Logs used as evidence have requirements ordinary operational logs do not.
| Property | Operational | Evidential |
|---|---|---|
| Retention | Days to weeks | Years, per requirement |
| Location | Often on the host | Off the host, immediately |
| Mutability | Rotated and overwritten | Write-once or demonstrably tamper-evident |
| Time accuracy | Approximate | Synchronised, with drift monitored |
| Access | Whoever administers the system | Restricted, with access itself logged |
| Completeness | Best effort | Gaps must be explainable |
The mutability row is the substantive one. Logs an administrator can edit are logs that prove nothing about an administrator, which is precisely the scenario audit logging exists for. Immutable or append-only storage is what makes the log evidence rather than a record.
The completeness row matters more than it appears. A gap in a log is not neutral — it is the shape an intrusion or a removed record leaves. Alerting on logs not arriving, and being able to account for any gap, is part of the control rather than an operational nicety.
Segregation of duties
No individual should be able to complete a sensitive process alone, and no individual should be able to alter the record of what they did.
This is straightforward to state and awkward in a small business, where the same person frequently performs several roles by necessity. The workable position is not to pretend otherwise.
- 1
Identify the combinations that matter
Typically: creating a payee and approving a payment; changing a permission and using it; deploying code and approving the deployment; administering a system and controlling its audit log.
- 2
Separate what can be separated
Even in a small team, the second person does not need to be senior — they need to be different.
- 3
Where separation is genuinely impossible, compensate
Independent after-the-fact review, alerting on the specific combination occurring, and a written record of why the compensating control was chosen.
- 4
Protect the audit trail from the administrators
This is the one separation that should not be compromised, because everything else depends on it.
Change control that produces evidence
Regulated environments need to demonstrate that changes were authorised, tested and reversible. Most growing businesses have change control as a habit rather than as a record.
- What changed, in enough detail to reconstruct it — which for code and configuration means version control rather than a description.
- Who requested it, who approved it, and that these were different people.
- What testing was performed, and its result.
- The rollback plan, and whether it was exercised.
- When it was applied, by whom, and whether it succeeded.
The efficient way to satisfy this is to make the evidence a by-product of the process rather than a document written afterwards. Version control, automated deployment and a ticket per change produce most of the record automatically, which is also why they are worth adopting for reasons unrelated to compliance.
Availability as a contractual property
Financial businesses commonly have availability requirements that are contractual or regulatory rather than aspirational, and there is a further requirement that ordinary businesses do not have: incidents must be reported, frequently within a defined window.
That reporting obligation changes the engineering. It means detection has to be reliable and timestamped, because the clock on the reporting window starts at detection, and a business that cannot say precisely when it detected something is in a poor position.
- Set recovery objectives per system from the actual obligation, not one target across the estate.
- Verify restore by performing it, and record the measured time — this is the figure that will be asked for.
- Ensure detection is timestamped and logged, because the reporting clock starts there.
- Rehearse the incident process including the notification path, not only the technical recovery.
Card data, where it applies
Where card payments are handled, PCI DSS applies and contains requirements that are specific rather than general. The one that most often catches businesses by surprise concerns telephone payments and call recordings, and it is covered in its own article.
The general principle worth carrying: the cheapest way to satisfy card data requirements is to hold as little card data as possible, and ideally none. Scope reduction beats scope compliance.
What makes IT for financial services different?
Not stronger controls — largely the same controls any business should have — but the standard of evidence. In an ordinary business a control that works is sufficient; in a regulated financial business, a control that works but cannot be demonstrated to have worked is treated as absent. Systems designed to function are not automatically systems designed to produce evidence, which is what reshapes the architecture.
Why do audit logs need to be immutable?
Because logs an administrator can edit prove nothing about an administrator, which is precisely the scenario audit logging exists to cover. Evidential logging requires logs written off the host immediately, stored write-once or in a demonstrably tamper-evident form, with synchronised time, restricted access that is itself logged, and gaps that can be accounted for — since a gap is the shape an intrusion or a removed record leaves.
How can a small team achieve segregation of duties?
By identifying the combinations that actually matter — creating a payee and approving a payment, changing a permission and using it, deploying code and approving it, administering a system and controlling its audit log — and separating what can be separated. The second person need not be senior, only different. Where separation is genuinely impossible, compensating controls such as independent after-the-fact review and alerting on the combination occurring should be documented with the reason. The one separation that should not be compromised is protecting the audit trail from the administrators.
What does evidenced change control require?
What changed in enough detail to reconstruct it, who requested and who approved it and that these were different people, what testing was performed and its result, the rollback plan and whether it was exercised, and when it was applied and whether it succeeded. The efficient approach is to make the evidence a by-product of the process — version control, automated deployment and a ticket per change produce most of the record automatically.
How do incident reporting obligations change the engineering?
They make reliable, timestamped detection a requirement rather than an operational preference, because the reporting clock typically starts at detection and a business that cannot say precisely when it detected something is in a poor position. It also means the incident process must be rehearsed including the notification path, not only the technical recovery, and that measured restore times should be recorded because they are the figures that get asked for.
Sources and further reading
- A cybersecurity checklist for growing businesses— the control set this adds an evidence standard to
- Centralised logging with Loki— getting logs off the host, which evidential logging requires
- Access control and offboarding— individual accounts, which attribution depends on
- Call recording: the obligations nobody checks— the PCI DSS requirement that catches telephone payments
- High availability for business systems— RTO and RPO derived from an obligation rather than a preference
- Data retention and archiving for growing businesses— retention periods, and copies an administrator cannot reach
- PCI Security Standards Council document library— the standard itself, where card payments are handled
- NIST SP 800-34 Rev. 1: Contingency Planning Guide— recovery planning structure behind the availability section
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.