Security, Continuity and Governance

You built (or inherited) a custom system years ago. It runs order processing, or stock, or HR, or all three. It works — until the one developer who understands it goes on holiday, or leaves, or retires. Then a report breaks, nobody knows why, and suddenly the question everyone should have asked earlier comes up: what actually happens to our business if this system fails, gets hacked, or the person who built it disappears?

This article answers that question directly: how do you make a custom system — FileMaker-based or otherwise — secure, resilient, and properly governed, without freezing it in place or being held hostage by a single developer?

Why is this suddenly urgent for custom software?

Most custom business systems — FileMaker solutions especially — grow organically. A quoting module gets added in year two. A connector to the accounting package in year four. An AI-assisted lookup for support tickets in year seven. Nobody planned it as "one platform," it just accumulated.

That accumulation is exactly where risk hides:

• Single point of knowledge. One in-house developer, or one freelancer, holds the only real map of how the system works. No documentation, no handover plan.
• Unmanaged access. Staff who left the company two years ago still have active logins. Admin passwords are shared in a spreadsheet.
• No real backup discipline. Backups exist, but nobody has actually tried restoring one in the last twelve months.
• Silent integrations. An API connector to a webshop or a logistics partner runs quietly in the background, with no monitoring, until it fails on a Friday afternoon and nobody notices until Monday.

None of this is unique to FileMaker — it happens to any custom-built ERP, CRM, or internal tool. But because FileMaker systems are often built and extended in-house rather than by a large vendor with a support contract, the governance gap tends to be wider.

What does "security" actually mean for a system like this?

Security for a custom business system is not just "do we have a firewall." It has to be answered on three levels:

1. Access security — who can see and change what, and can you prove it? Role-based permissions (not "everyone is admin because it's easier") are the baseline. In FileMaker, this means using privilege sets deliberately, not defaulting every account to full access during development and forgetting to lock it down before go-live.
2. Data security — is data encrypted in transit and at rest, and are external connections (web publishing, APIs, mobile access) properly secured rather than left on default settings? A connector that pushes customer data to a webshop over an unsecured endpoint is a real, common gap — not a theoretical one.
3. Application security — is the software itself kept patched and current? An old, unsupported FileMaker Server version, or a plugin that hasn't been updated in three years, is a known attack surface, not a minor housekeeping item.

A concrete example: a manufacturing client had a FileMaker system exposed via WebDirect for external sales reps, still running on server software two major versions behind. It worked fine — until a routine security review flagged that the version in use no longer received security patches at all. The fix wasn't dramatic, but it had been postponed for two years because "nothing was broken."

What does "continuity" mean in practice?

Continuity is the answer to: if something goes wrong tomorrow, how long are we down, and what do we lose?

A practical continuity check looks at:

• Backup frequency and testing. Daily backups are common; untested backups are common too, and that's the actual danger. A backup you've never restored is a hope, not a plan.
• Recovery time. If the server hosting your FileMaker solution goes down, do you know — concretely, in hours — how long it takes to get back to a working state? Have you ever timed it?
• Knowledge continuity. Is there documentation of the schema, the scripts, the integrations — something a new developer could pick up without three weeks of archaeology? This is where many FileMaker systems fail hardest: the system is technically fine, but only one person can safely touch it.
• Vendor/developer continuity. If your freelance developer becomes unavailable, do you have the files, the credentials, and enough documentation to bring in someone else? This single point is, in our experience, the most common and most avoidable continuity risk in custom software.

What does "governance" mean for a system nobody officially owns?

Governance is the least technical of the three, and the most often skipped — because it's a process question, not a code question. It answers: who decides what changes, who approves access, and who is accountable when something goes wrong?

A workable governance setup for a custom system usually includes:

• A named business owner (not just "IT" or "the developer") who is accountable for the system — usually someone in operations or management, not only the person who built it.
• A change process, even a lightweight one: new features or schema changes get logged, reviewed, and tested before going live — not pushed straight into the production file on a Tuesday afternoon.
• An access review cadence — quarterly or at least twice a year, someone actually checks who has access and revokes what's no longer needed.
• A documented decision trail for anything touching security or data — why was this API connector approved, who signed off on this AI feature accessing customer records, and where is that written down?

This matters more, not less, as systems get smarter. If you're adding AI-assisted features — for example using a tool like Klai to let staff query data or generate reports through natural language inside FileMaker — governance has to extend to that layer too: what data can the AI feature actually see, is that appropriate, and who approved it?

How do AI and modern tooling change the risk picture?

Adding AI capabilities into a business system (chat-style querying, automated summarization, AI-assisted form generation) is genuinely useful — but it introduces a new governance question that didn't exist five years ago: what data is being sent where, and can it be scoped and audited?

If an AI layer inside FileMaker can query the full customer database to answer a support question, that's a security and governance decision, not just a feature toggle. The right approach is the same principle as access control generally: scope it. Give the AI feature access to only what it needs for its job, log what it's asked and answered, and review that periodically — the same way you'd review any employee's access rights.

The same logic applies to modern interface layers. Tools like FmBetterForms, which modernize how users interact with a FileMaker back end through a browser-based front end, are genuinely good for usability and mobile access — but they also expand the attack surface and the number of places where access control has to be enforced consistently. A modern front end is not a substitute for solid permission design underneath it; it's an additional layer that has to inherit the same discipline.

A practical checklist: is your custom system actually under control?

Go through this honestly — most systems fail at least two or three of these:

• Backups are tested by an actual restore at least twice a year
• User access is reviewed at least twice a year, and ex-employees are removed promptly
• There is more than one person who could take over development if the current developer left tomorrow
• Server software, plugins, and any AI or integration tools are on supported, patched versions
• Every external connector (webshop, accounting, logistics, e-commerce) has monitoring or alerting, not silence-until-it-breaks
• Any AI feature with data access has a defined scope, and someone has reviewed what it can see
• There is a named business owner for the system, not just a technical contact
• Changes go through some form of review before hitting production, however lightweight

If you checked fewer than six of these, the system is running on trust rather than governance — which usually works fine, until the day it doesn't.

FAQ

Does this apply to small businesses too, or only larger companies? It applies earlier than most small businesses expect. A five-person company running its entire order process on one FileMaker file built by one part-time developer is, in continuity terms, more exposed than a larger company with a team — because there's no redundancy at all.

Is moving to a "proper" ERP the real fix? Not necessarily. Governance and continuity are process and documentation problems as much as technology problems. A well-governed custom system can be more reliable than a poorly configured off-the-shelf ERP. The platform matters less than whether someone is actually accountable for it.

How often should security and continuity actually be reviewed? At minimum, an annual review covering access, backups, patch levels, and integrations — with a lighter access check every quarter. Treat it like a fire drill: infrequent but non-negotiable.

We're adding AI features — does that really need a governance step? Yes. Any feature that can read or summarize business data should have its data scope defined and reviewed, exactly like a new employee's access would be — AI doesn't get a free pass just because it's a feature rather than a person.

Getting security, continuity, and governance right in a custom system isn't a one-time project — it's an ongoing discipline that most companies only invest in after a scare. If you want a clear picture of where your current FileMaker system, integrations, or AI features actually stand, Loggix can help map the real risks, tighten access and permission design, document what's currently only in one person's head, and build in the monitoring or handover plans that turn a fragile system into a genuinely resilient one — whether that means hardening what you have, connecting it more safely to other systems, or planning its next stage together.