Business application security: access, audit trail, backups

What business application security actually means#

Business application security means that before go-live, it is already clear who can access which data and functions, how every important change is logged, and where and how backup copies of the data are kept. These are not three separate technical settings but a set of decisions the vendor must work out with the client before the system is first released into production. Without these decisions, security is left to chance, and an incident is often the first moment anyone learns who was actually responsible for a given part of the system.

A business application in a multi-department company rarely stands alone. It connects to ERP and CRM systems, document archives and reporting tools, so every new API connection widens the surface where unauthorised access or data loss can occur. Responsibility for security therefore extends to every connected system, not just the application itself. An IT lead or project director should require the vendor to review the whole chain, not a single component in isolation.

For a decision-maker, this means security cannot be left to the vendor as an assumed background service. These are questions to raise before signing the contract: who decides access rights, how are changes tracked, and who is accountable if a backup turns out to be unusable. The answers determine how quickly the company recovers from an outage or error, and who bears responsibility for the consequences.

Managing access to the application and its data#

The first decision the vendor must settle is who can see and edit which part of the system. This means mapping user roles by department, separating read rights from edit rights, and clearly defining who can grant or revoke another user's access. Without this mapping, employees who have no operational need for financial or HR data often end up with access to it anyway.

In an application shared by several departments, risk grows because roles change over time. An employee switches departments, covers for a colleague, or leaves the company, and access rights are frequently left unchanged. The vendor should propose a way to review access regularly and connect the system to HR records so permissions adjust automatically as employment status changes.

For the client, this means appointing an owner for each data domain before the project starts - the person who decides who may access it. This responsibility cannot be handed entirely to the vendor, who does not know the company's internal structure. Agreeing on roles jointly at the outset prevents later disputes over who approved an access that turned out to be a problem.

• Mapping user roles by department and access level
• Separating the person who enters data from the one who approves it
• Dedicated oversight of administrator accounts
• Regular review of granted rights and immediate revocation on termination
• Linking access to HR records so role changes update permissions automatically

Audit trail: who did what, and when#

An audit trail is a record of who accessed the system, what they changed, and when it happened. The vendor must ensure this record is immutable - even a user with administrator rights should not be able to delete or edit it afterwards. Without such a trail, a company facing an incident or dispute has no basis for establishing what actually took place.

An audit trail matters most when a dispute arises between departments, an inspection is under way, or data misuse is suspected. A system that only stores the latest value of a record, not the history of changes, cannot reconstruct who caused an error and when. This matters especially for applications handling financial, HR or personal data, where traceability is often also a legal requirement.

Before signing a contract, the client should ask the vendor for a clear description of what the system logs and how long records are kept. It is equally important that the audit trail is stored separately from the production database, so that an error or attack on the main system does not also destroy the evidence of what happened. This question needs to be settled at the architecture stage, not after an incident.

• User logins and logouts
• Changes to business-critical data, recording old and new values
• Data exports or transfers out of the system
• Changes to user rights and administrator access grants
• Deletion of records or entire datasets
• Administrator access to the production environment

Backups and disaster recovery#

A backup is not just a copy of data kept elsewhere - it is an agreed plan for how quickly and in what state the system returns to operation after data loss or an outage. The vendor must define how often backups are made, where they are stored, and who is responsible for verifying them. Without this agreement, it often only becomes clear after an actual data loss that the backup does not exist or does not work.

Data loss can result from human error, infrastructure failure or a ransomware attack. In every case, it is essential that the backup is not stored in the same location as the production system, or the same attack or failure destroys the backup too. It must also be clear how long old backups are retained and when they get overwritten by newer ones.

For the client, the key question is whether restoring from a backup is actually tested regularly, not just performed. A backup that has never had to be restored may be corrupted without anyone knowing. The vendor's maintenance agreement should therefore specify how often a test restore is carried out and who reports the result to the responsible person in the company.

• Backup frequency matched to the criticality of the data
• Backups stored separately from the production environment
• Encryption of backups in transit and at rest
• Regular testing of an actual restore, not just backup creation
• A clear retention policy for how long old backups are kept
• A disaster recovery plan for a major outage

Separate development, test and production environments#

A change to a business application should never be tested directly on the system employees or customers actually use. The vendor must provide a separate development environment where changes are built, a test environment where they are verified, and a production environment they only reach after approval. This separation is the basic safeguard that keeps a development mistake from causing an outage in the live system.

Real personal data belonging to customers or employees must never be used in the test environment. Test or anonymised data is used instead - structurally similar to the real thing, but revealing no actual individuals. This matters both for data protection and because test data can leak more easily out of a less secured environment.

For an IT or project lead, this means checking before the engagement starts whether the vendor actually separates environments or whether it is just a claim in the proposal. Who has access to the test environment, and what data sits in it, is a question worth raising at the first meeting, not after the first incident.

Testing before every production release#

Every change to a business application must go through review and testing before it reaches production. The vendor checks that the change works as agreed and has not broken other parts of the system. Skipping this step raises the risk that a small fix causes an outage in a completely different, seemingly unrelated part of the application.

Testing includes manual checks of critical functions, automated testing of the user interface, for example with tools such as Playwright and Cypress, and API and regression testing that confirms existing functionality still works after a new change. These checks can also run inside an automated release pipeline (CI/CD) so verification does not get forgotten or skipped under time pressure.

For business-critical systems, it is worth adding acceptance testing against criteria agreed in advance, where the client confirms a change meets requirements before it goes live. For larger or higher-risk projects, it is advisable that testing is carried out by an independent team, separate from the developers, since a developer rarely catches their own mistake.

• Manual checks of critical business functions
• Automated UI testing (for example Playwright, Cypress)
• API testing and testing of connections to other systems
• Regression testing after every major change
• Testing inside the CI/CD release pipeline
• Acceptance testing against criteria agreed in advance
• Independent QA, separate from the development team, on higher-risk projects

Maintenance and responsiveness after go-live (SLA)#

Once an application is in use, security is not a finished task - it continues through maintenance. After go-live, the vendor can take over monitoring, bug fixing, and technical and security updates. The key is that this is agreed in advance, with clearly defined severity classes and handling priority, not improvised once an actual disruption occurs.

Faults are typically sorted into severity classes. An outage means the system or a key part of it is not working, and gets the highest priority. A disruption means the system works but a particular function does not, handled at an agreed priority. A minor fault with no business impact is scheduled into the next regular release, while a request for a change or upgrade is scoped and scheduled separately.

For the client, it matters that these classes and handling rules are written into the maintenance contract, not agreed verbally. Actual response times are set according to the system's criticality and agreement between client and vendor, since they differ depending on whether the system is used by a handful of staff or the whole business depends on it.

• Class 1 - outage: the system or a key part is down, handled with the highest priority
• Class 2 - disruption: the system works but a function does not
• Class 3 - minor fault: no business impact, scheduled into the next release
• Class 4 - request: a change or upgrade, scoped and scheduled separately

Ownership of code, data and documentation#

The source code and data of a business application belong to the client, not the vendor. This must be written into the contract, since it determines what happens if the company decides to switch vendors or bring the project in-house. Without this clause, a company can end up locked into a single vendor regardless of the quality of their work.

Alongside the code, documentation matters just as much: an architecture description, a list of access credentials, and an explanation of how the system works. All of this is part of the handover and must be available to the client whether the engagement continues or ends. Documentation that exists only in one developer's head is a risk in itself.

When a company takes over an existing or unfinished system from another vendor, the first step is a review of the source code, architecture, infrastructure and data. Only on that basis can anyone judge whether the system is secure, documented and ready for further development, or whether parts of it need fixing before an upgrade can even begin.

How to choose a vendor for application security#

When choosing a vendor, check whether they have experience with security architecture, access management (IAM), vulnerability testing and incident response. These are areas that are hard to judge from a pitch alone, so it is worth asking for a concrete example of how the vendor handled a similar task on a project of comparable size.

On this type of project, Epix works with a specialist partner network that includes experts in security architecture, penetration testing, vulnerability management, digital forensics and incident response. Certified professionals in cloud security, identity management and project management are also part of this network, and quality- and information-security-management standards are built into the delivery structure the projects follow.

For the client, this means that on a larger project they are not relying on a single developer but on an assembled team where each member has a clear role. It is also worth checking whether the vendor understands the requirements of the client's industry - for example the public sector, banking or healthcare, where traceability and security requirements are often stricter than elsewhere.

• Experience with security architecture and access management (IAM)
• Experience with vulnerability testing and incident response
• Access to digital forensics specialists within the partner network
• Quality- and information-security-management standards in the delivery structure
• Experience in a regulated industry such as the public sector, banking or healthcare
• A clear maintenance contract with defined fault classes

Price and scope of work#

The price of securing a business application cannot be given without reviewing the specific system, which is why we do not publish general figures. It is more useful to turn the question around and ask which factors actually determine the scope of work, since those factors say more than any rough number could.

Scope is shaped by security, audit-trail and compliance requirements, which are stricter in the public sector or regulated industries than elsewhere, by the volume and condition of the data that needs to be protected or migrated, and by whether the work is a new system or a takeover and upgrade of an existing one. The level of post-launch support and agreed response classes are also significant factors.

Before preparing a quote, Epix proposes a short analysis that breaks the scope into individual work packages - access, audit trail, backups, testing and maintenance - so each package can be estimated and delivered separately. This lets the client see where most of the effort lies and decide which part to take on first and which to schedule later.