How to protect confidential business information

Your customer list, your pricing agreements, your supplier contracts, your HR files — all of it probably lives inside a handful of business systems that half your company can open with one shared login. Most owners only discover how exposed that data really is after something goes wrong: an ex-employee still has access three months after leaving, a spreadsheet with salary data gets emailed to the wrong group, or a consultant walks off with a full export of the customer database on a USB stick.

This article walks through exactly how to lock down confidential business information in the systems you actually use day to day — without turning your team into a compliance department.

What counts as "confidential business information"?

Before you can protect it, you need to know what you're protecting. In a typical FileMaker or ERP-driven business, confidential data usually falls into these buckets:

• Customer data — contact details, order history, pricing agreements, contracts.
• Financial data — margins, invoices, payroll, bank details.
• Employee data — HR records, performance reviews, salary information.
• Strategic data — supplier terms, product formulas, roadmaps, unreleased pricing.
• Operational data — production schedules, inventory levels, internal SOPs.

A useful test: if this record leaked to a competitor or made the local news, would it hurt you? If yes, it belongs on your protected list — and it needs an owner, not just a folder.

Why do internal systems leak confidential data more often than hackers steal it?

In practice, most confidential data exposure inside SMBs isn't a hacker breaking in from outside — it's an internal access problem. A few patterns show up again and again:

1. One shared admin login. Everyone logs into the FileMaker solution or ERP with the same account, so there's no way to tell who actually viewed the salary layout on a given day.
2. Over-permissioned users. A warehouse employee can open the finance module because "it was easier to just give everyone full access."
3. Orphaned accounts. A former employee's account is still active, still syncing to their phone, six months after they left.
4. Unencrypted exports. Someone exports a customer list to Excel "just to check something" and it sits, unprotected, in a Downloads folder or gets emailed as an attachment.
5. Plugged-in AI tools with no guardrails. A well-meaning team member pastes a batch of customer records into a public AI chatbot to "clean up the formatting," not realizing that data may now be used to train a public model.

None of these require a sophisticated attacker. They require a system that was never designed with confidentiality in mind — and that's fixable.

How do you actually lock down confidential data? A step-by-step approach

1. Classify your data before you configure anything

Tag tables, layouts, or modules by sensitivity level — public, internal, confidential, restricted. This sounds bureaucratic, but in a FileMaker solution it can be as simple as a privilege set per sensitivity tier. Skipping this step is why most access control efforts fail: you can't set the right permission if you never decided what the record deserves.

2. Move away from one shared login — always

Every user should have their own named account. In FileMaker this means individual accounts tied to privilege sets, not one generic "Staff" login. The same applies to your ERP, your cloud storage, and any connected API. Named accounts are what make audit logs meaningful — without them, "who accessed this record" is an unanswerable question.

3. Apply least-privilege access, by role and by record

Give people access to what their job requires, nothing more. In practice this looks like:

• Sales reps see their own accounts, not the full customer database.
• Warehouse staff see inventory, not margins.
• HR sees personnel files; finance sees payroll; nobody sees both unless their role genuinely requires it.

FileMaker's privilege sets support this down to the field level — you can let someone see a customer record but mask the credit terms field, for example. That granularity is often underused because it takes deliberate design, not because the tool can't do it.

4. Encrypt data at rest and in transit

Confidential fields — bank details, salary data, personal identifiers — should be encrypted in the database itself, and every connection (client to server, server to any integrated API) should run over TLS. If you're moving data between FileMaker and another system through a custom API connector, that connector is a security boundary too, not just a convenience layer — treat its authentication and encryption with the same seriousness as the database itself.

5. Log access, not just changes

Most systems log who changed a record. Fewer log who viewed it. For genuinely confidential data — HR files, financials — you want both. An audit trail that shows "this salary record was opened by this user on this date" is often the difference between containing an incident quickly and spending weeks guessing what happened.

6. Set an offboarding checklist and actually run it

Access review shouldn't only happen at onboarding. Every departure should trigger:

• Immediate deactivation of accounts (not just password changes).
• Revoking API keys or tokens issued to that person.
• Removing device-level sync (mobile FileMaker Go clients, cloud drive access).
• A review of what that person exported or downloaded in their final 30 days.

7. Set clear rules for AI tools touching your data

If your team uses AI — whether a public chatbot or an AI feature built into your own software — confidential records should never be pasted into a public model without controls. This is one reason more businesses are choosing to run AI capabilities inside their own FileMaker environment, where the AI only ever touches data within the same access-controlled, audited system, rather than sending it out to a third-party tool with unknown data retention policies.

What does this look like in a real FileMaker environment?

A mid-sized distributor we've seen in this situation had one login shared across the whole sales team, because "it was faster." Every rep could open every customer's pricing, every contract note, every internal margin calculation — including pricing given to their biggest competitor's sister company. When a rep left to join that competitor, there was no way to know what they'd viewed or exported in their last weeks, because there were no individual accounts and no view-level logging.

The fix wasn't exotic: individual named accounts, privilege sets split by role (sales vs. finance vs. management), field-level masking on margin data for non-management users, and an offboarding checklist tied to HR's exit process. None of this required rebuilding the system — it required treating access control as a design decision, not an afterthought.

How do you know if your current setup is actually protecting confidential data? A quick checklist

• Every user has an individual login — no shared credentials.
• Access is scoped by role, down to the field level where it matters (salary, margins, contracts).
• Confidential fields are encrypted at rest; all connections use TLS.
• You can answer "who viewed this record last month" in under five minutes.
• Departing employees are deactivated the same day, including API keys and mobile sync.
• Exports of confidential data are logged, or restricted entirely for most roles.
• Any AI tool touching your data operates inside your access-controlled environment, not a public model.
• Someone in the company is explicitly responsible for reviewing access permissions quarterly.

If you can't check most of these boxes today, that's not a reason to panic — it's a reasonably common starting point, and each item above is fixable independently.

FAQ

Does GDPR require encryption of confidential business data? GDPR doesn't mandate a specific encryption standard, but it does require "appropriate technical measures" proportionate to risk — and encryption is consistently cited by regulators as a baseline expectation for personal data. For non-personal confidential data (pricing, contracts), it's simply good practice, not a legal requirement.

Is it enough to just password-protect a FileMaker file? No. A single file password protects against casual snooping, not against internal misuse or accountability gaps. Named accounts, privilege sets, and audit logging are what actually let you answer "who did what" — a shared password can't do that.

Can confidential data protection slow down our team? If designed well, no — least-privilege access should be invisible to someone who only ever needs their own scope of data. It only "slows down" people who were relying on over-broad access they didn't need in the first place.

Should confidential data ever leave our core system for reporting or AI tools? Ideally it stays inside the access-controlled system. If it must move — to a BI dashboard, a reporting tool, or an AI feature — that connection should be authenticated, encrypted, and scoped to only the fields genuinely needed, not a full data dump.

Protecting confidential business information isn't a one-time project — it's an ongoing part of keeping business-critical software secure and reliable, which we cover in more depth in our guide on how to secure and maintain business-critical software. If your current FileMaker solution, ERP, or API integrations were never designed with this level of access control in mind, Loggix can help you assess where the real exposure sits and rebuild the permission structure — or add AI tools — without disrupting how your team already works.