How to secure and maintain business-critical software

Somewhere in your company there's a system that, if it went down for a day, would stop invoices from going out, stop orders from being picked, or stop your service team from helping customers. Most businesses know exactly which system that is. Far fewer can say with confidence who last checked its access rights, when it was last backed up and tested, or what happens if the developer who built it leaves.

This article walks through what it actually takes to keep business-critical software secure and maintainable over the long run — not as a one-time project, but as an ongoing discipline.

What makes software "business-critical" in the first place?

A system earns that label when its failure has a direct, immediate financial or operational impact. Useful test questions:

• If this system is down for 4 hours, does revenue stop moving?
• If this system is down for a full day, do customers notice?
• Is there a manual fallback, or does work simply stop?

For many SMEs this is an ERP system, a custom FileMaker application running order processing or warehouse logistics, or an API connector syncing orders between a webshop and accounting software. If the honest answer to any of the questions above is "yes," the system belongs in a formal security and continuity plan — not just in the head of whoever built it.

Why do custom and legacy systems get neglected on security?

Off-the-shelf SaaS products usually push security updates automatically and market their compliance certifications loudly. Custom-built or platform-based systems — a FileMaker solution built ten years ago, a set of Excel macros that quietly became critical, an internal tool nobody remembers commissioning — don't advertise their risk the same way. That silence gets mistaken for safety.

In practice, three things usually go wrong:

1. Nobody owns it. The original developer left, moved to another team, or was a freelancer who's no longer reachable. No one is responsible for patching or reviewing it.
2. Access accumulates. Accounts get created for projects, contractors, and interns, and never get removed. Two years later, six former employees still have login credentials to the order system.
3. "It still works" is treated as "it's still secure." A system can run perfectly fine on the outside while running on an unsupported database engine, an outdated plug-in, or a certificate that expired without anyone noticing until a client complains their forms won't load.

What does a real security and maintenance plan look like?

A workable plan for a business-critical system covers four layers. Skipping any one of them is how companies end up with a system that's backed up but not secure, or secure but with no continuity plan if the server dies.

1. Access control

• Every user account is tied to a named person — never a shared login.
• Access is role-based: a warehouse picker doesn't need access to the pricing tables; a finance user doesn't need admin rights over the database schema.
• Access is reviewed at least twice a year, and immediately when someone leaves.
• Admin/developer accounts use multi-factor authentication, full stop — this is the account attackers target first because it unlocks everything else.

2. Data protection

• Data is encrypted in transit (TLS) and, where the platform supports it, at rest.
• Backups run automatically — and are restored on a test system on a schedule, not just created and trusted blindly. A backup nobody has ever restored is a hope, not a plan.
• Sensitive fields (salary data, personal customer data, medical or HR records) get extra field-level protection or encryption, not just the same access rules as everything else.

3. Patch and dependency management

• Server OS, database engine, and any plug-ins or connectors follow a documented update schedule — not "whenever someone remembers."
• Third-party plug-ins are the most commonly forgotten piece: a FileMaker solution using an old barcode-scanning plug-in that hasn't been updated in years is a real, common example of a quiet vulnerability sitting inside an otherwise well-run system.
• Updates get tested in a staging copy of the system before touching production — a five-minute check that has saved countless businesses from an update breaking a critical script mid-workday.

4. Continuity and recovery

• A written, specific answer to: "If this server disappears tonight, what do we do tomorrow morning?"
• A named person (not "IT" in the abstract) responsible for triggering recovery.
• A tested recovery time — not an assumed one. Many businesses discover their real recovery time is 3 days, not the 3 hours they assumed, only during an actual outage.

How do AI tools and low-code add-ons change the security picture?

Modern business systems increasingly plug in extra capability rather than building it from scratch — an AI assistant reading incoming invoices, a service like Klai adding conversational AI on top of a FileMaker database, or a forms tool like FmBetterforms rendering web-friendly forms for a system that started as a desktop application. These additions genuinely improve usability and speed. They also each open a new door that needs the same governance as the core system:

• What data does the add-on actually see? An AI layer that reads customer records to answer questions needs the same access review as a human employee would.
• Where does the data go? If an AI service processes data outside your own infrastructure, that's a new data-processing relationship — it belongs in your data protection policy and, in the EU, your GDPR documentation.
• Who patches the connector? A forms layer or AI integration is still software. It needs a named owner and a place in the patch schedule, exactly like the database itself.

The mistake to avoid is treating these tools as "just a plug-in" that sits outside the security conversation. In practice, they're new endpoints into the same critical system and should be governed as such.

Who should actually own this, day to day?

Security and continuity fail most often not from a lack of tools, but from a lack of a named owner. A workable model for most SMEs:

• A business owner or IT manager who owns the risk decision — how much downtime is acceptable, what budget continuity gets.
• A developer or technical partner (internal or external) who owns the technical execution — patching, backups, access configuration.
• A short written policy, even one page, stating who does what and how often. It doesn't need to be a 40-page compliance document to be effective; it needs to actually get followed.

A practical checklist: is your business-critical system actually covered?

• We know exactly which systems in our company are business-critical.
• Every user account is named, not shared, and reviewed twice a year.
• Admin and developer access requires multi-factor authentication.
• Backups are automated and test-restored on a schedule.
• There's a documented patch schedule for the OS, database, and all plug-ins/connectors.
• Updates are tested on a staging copy before going live.
• There's a written, named recovery plan with a tested recovery time.
• Any AI tool or add-on connected to the system has been reviewed for data access and processing location.
• One named person owns this plan — and reviews it at least annually.

If you can't check most of these boxes today, that's not unusual — it's the normal state most companies discover their critical system is actually in, once someone finally asks the question.

FAQ

How often should a business-critical system be security-reviewed? At minimum annually, and after any major change — a new integration, a new AI tool connected, a change of hosting provider, or a change in who has admin access.

Is a custom FileMaker system less secure than an off-the-shelf ERP? Not inherently — FileMaker systems can be built with strong encryption, role-based access, and audit logging. The risk isn't the platform, it's whether the system has an active owner keeping it patched and reviewed. An unmaintained ERP is just as exposed as an unmaintained FileMaker app.

What's the single highest-impact first step if we've never done this? Run the access review first. It's the fastest way to find real exposure — former employees, shared logins, over-broad permissions — and it costs nothing but time.

Does adding AI to our system increase our compliance obligations? Often yes, particularly under GDPR if personal data is processed by a third-party AI service. It's worth mapping exactly what data reaches the AI layer before rolling it out company-wide, not after.

This kind of review connects directly to the broader question of how a company keeps its software landscape secure, resilient, and well-governed over time — a theme explored in more depth in Loggix's Security, Continuity and Governance knowledge domain.

If this checklist surfaced more gaps than you expected, that's a normal starting point, not a crisis. Loggix works with businesses on exactly this kind of situation — reviewing an existing FileMaker or ERP system's access model and update history, building or hardening the API integrations and AI tools connected to it, and mapping out a realistic, prioritized plan so security and continuity stop depending on one person's memory and start being part of how the system runs.