Security Basics for a Custom Business System: Audit Trail, Backups and What to Ask Your Builder

Before you commission a custom business system, you will be asked to approve screens, features and a price. Rarely does anyone ask you to approve how the system will be protected, yet this is the part that decides what happens on the bad day: a staff member deletes the wrong customer list, a salesperson's password is guessed, a price is changed and nobody knows by whom, or the server fails on the 28th of the month.

This guide is for owners and managers who are not technical and are about to hire a builder, whether a freelancer, an in-house developer or a software company. It does not teach you to secure a system yourself. It gives you the plain-language questions to ask, what a good answer sounds like, and what to put in the written quote. It is general guidance, not legal advice and not a description of any supplier's methods. For who can see and do what, it points to an existing guide rather than repeating it; the focus here is the audit trail, backups with a restore test, logins and the due-diligence questions that tie them together.

Security in plain words: three questions

You do not need security vocabulary to judge a builder. Almost every safeguard answers one of three questions:

• Who can get in, and what can they do? Accounts, roles, passwords and two-step verification.
• What happened, and who did it? The audit trail, plus the activity records behind it.
• If it goes wrong, can we get back? Backups, a tested restore, and how the system is hosted and updated.

A fourth question runs underneath all three: what personal data do we hold, and who is responsible for it? Because the answer touches the law, it gets its own section below.

Be wary of anyone who answers a security question with "don't worry, it's fully secure" or "100% safe". No system is perfectly safe. A good builder talks about what is protected, what is recorded, how you would find out something went wrong and how you would recover. If you hear only reassurance, ask for the specifics in writing.

Who can see and do what

Roles are the first safeguard, and the audit trail depends on them. If everyone shares one login, the record can only say "the office did it". So the first due-diligence item is simple: every person has their own account, and each role sees and changes only what the job needs. Deciding that properly (owner, manager and staff roles, the six actions to decide for each kind of record, approval limits and what to do when staff join or leave) takes a guide of its own, so it is not repeated here. Read who should see what: user roles and permissions in a custom business system first, then come back to the audit trail, backups and logins below.

The audit trail: who changed what, and when

An audit trail (also called an audit log or activity history) is a record the system keeps automatically of significant actions: who did it, what they did, to which record and when. It is not the same as a "last modified" field, which only shows the latest change. An audit trail keeps every change in order.

Here is a made-up example. A customer complains that the price on a quotation was RM2,400 last week and now says RM2,000. With an audit trail, you open the quotation's history and read: "3 November, 4:12pm, Aisha (sales), changed unit price from RM2,400 to RM2,000, discount approved by Mr Lim." Without one, you are left asking around the office and guessing.

An audit trail is useful for four everyday reasons:

• Settling disputes. It answers "who changed this?" without blame or guesswork.
• Catching mistakes early. A wrong bulk edit or deletion can be found and reversed, because you can see exactly which records were touched.
• Deterring misuse. People behave differently when they know changes to prices, stock and customer details are recorded.
• Supporting your accountant or auditor. A clear history of financial changes makes year-end questions much easier.

The trail does not have to cover every click. Recording everything makes the log huge and unreadable. Decide with the builder which events matter to your business and keep it to those.

What to log, and what to keep out of the log

Use this table as a starting list and adjust it. The right set depends on your business: a clinic and a trading company will care about different records.

Just as important is what the log must not contain: passwords, full payment card numbers or other secrets. The log is itself a store of information, so ask the builder how sensitive details such as identity card numbers are handled in it.

Then ask how the log itself is protected. A trail that the people it records can edit or delete is worth little. Questions to put to the builder:

• Who can read it? Usually owners and designated managers, not all staff.
• Can anyone edit or delete entries? Ordinary users should not be able to, and administrators should be limited.
• How long is it kept? Agree a period that suits your business. For accounting records, ask your accountant what you need to retain.
• Can you search and export it? A log you cannot search by record or by person is hard to use when it matters.
• Is it included in the build? Do not assume it is. Ask for it as a named item in the quote.

Backups: what is copied, how often and where

A backup is a copy of your data kept separately, so that you can recover if something is lost, damaged or deleted. For a business system, "the backup" is not one thing. Ask which of these are covered:

• The database. Customers, orders, invoices, stock and every other record. This is usually the most valuable part.
• Uploaded files. Quotations, photos, signed documents and attachments, which are often stored apart from the database.
• Settings and the code. The configuration and the program itself, so a replacement server can be set up without starting from scratch.

Then ask the four questions that matter:

• How often? Frame it as work you can afford to lose. If the system failed at 5pm, would you accept losing the whole day's entries, an hour's entries or none? That answer sets how frequent the backups need to be, and it may cost more to lose less.
• Where are the copies? A backup kept only on the same server dies with that server. Ask for at least one copy in a different place.
• How many past copies are kept? An old copy is the way back from a mistake noticed days later, such as a wrongly imported file.
• Who can reach or delete them? Backups hold all your data, so access should be limited to named people, and the copies should be hard to delete by accident or by someone who has taken over an account.

A hosting company's backups and your system's backups are not automatically the same thing. A host may copy the server's files on a schedule without anyone checking that your system's database can be put back in a usable state. Ask the builder to say in writing which backups exist for the system's data, who is responsible for each and who pays. For the website side, with its own files and database, see the website backup guide; this guide is about the data inside your business system.

The restore test: a backup you have never restored is a hope

The most useful question you can ask a builder is also the simplest: "When did you last restore this from a backup, and did it work?" Backups can run for months and still fail on the day, because of a missing file, a damaged copy or a restore nobody had practised. A restore test proves the whole chain works.

Ask the builder to run one before go-live, using a separate test copy of the system so that live data is never touched:

1. Pick a backup. Choose a real one, not a copy made specially for the test.
2. Restore it to a separate environment. Not over the live system.
3. Check it. Log in, count records against a known figure, open a few recent orders, confirm that uploaded documents open, and check that the newest entries from the backup time are there.
4. Time it. Write down how long it took, because that is roughly how long you would be without the system.
5. Write down the steps and who does them. On a bad day the person who built it may not be available.
6. Agree when it repeats. Put a rhythm in writing, for example after major changes and at agreed intervals.

Treat it as part of acceptance. The guide to user acceptance testing shows how to build a sign-off checklist, and "restore test passed" belongs on it.

Logins: passwords and two-step verification

Most break-ins use a stolen, reused or guessed password rather than clever technical tricks. So the basics matter more than anything exotic:

• One account per person. No shared logins, so the audit trail means something.
• No default passwords left behind. Ask that any starter or built-in admin password is changed or removed before go-live.
• Long, unique passwords. Length helps more than clever symbols, and a password manager makes it practical. Staff should not reuse a password from another site.
• Protection against repeated guessing. After several failed attempts the system should slow down or lock the account.
• A safe reset process. Resetting should not let a stranger take over an account just by knowing an email address.
• Passwords stored safely. Ask whether passwords are kept in a form that even the developers cannot read back. The answer should be yes.

Two-step verification (also called two-factor authentication or 2FA) asks for a second proof, such as a code from an app on the person's phone, in addition to the password. It stops a stolen password from being enough on its own. At minimum, ask for it for administrators and for anyone who can see money or personal data, and ask whether it can be switched on for everyone. App-generated codes are generally considered stronger than codes sent by text message, though a text code is better than nothing. Also ask what happens when someone loses their phone, because that recovery step must not become the easy way in.

Disable a leaver's account the same day they leave; the joiner, mover and leaver routine in the roles guide covers it. For logins to the hosting account itself, see securing your cPanel hosting account.

Hosting and updates, briefly

You do not need to learn server administration, but you should know the answers to a few questions, because they affect everything above:

• Where does it run, and who runs it? Your own hosting account, the builder's, or a third party. Whose name is on the account?
• Is the connection encrypted? The system should be reached over HTTPS, the padlock in the browser, so data is not readable in transit.
• Is there a separate test copy? Changes should be tried on a test copy, not on the live system your staff use.
• Who applies updates, and how are you told? Software the system is built on keeps being updated, and fixing known weaknesses depends on someone doing it. Ask whether that is in the build, in a maintenance arrangement or nobody's job. Software maintenance after launch explains the difference.
• Who has access to live data? Developers sometimes keep access after a project ends. Ask that access is limited to what is needed and removed when it is not.

Personal data: handle it with care and confirm the rules

Most business systems hold personal data about customers and staff: names, phone numbers, addresses, sometimes identity card numbers or health details. The principle for you as the owner is simple: collect only what you need, let only the right people see it, keep it only as long as needed, and know how to correct or delete it.

Put this to your builder in practical terms:

• Do we need this field at all? Do not collect an identity card number just because a form can.
• Can we find, correct and delete one person's data? Ask how it would be done, including from backups.
• Can we export what we hold? You may need it for a request, and it also means you are not locked in.
• Is real customer data used in test copies? If so, it needs the same care as the live system, or use made-up data instead.
• What happens if something goes wrong? Agree in advance who is told, who investigates and who decides what to say to affected people.

Malaysia has a data protection law, the Personal Data Protection Act 2010 (PDPA), which has been amended in recent years, including new duties around certain data breaches. Whether and how it applies to your business depends on your circumstances. This guide is not legal advice, so please confirm what applies to you with the official source, the Personal Data Protection Commissioner's materials, or with a lawyer, and then put your requirements in the brief.

Questions to ask your builder

Take these to the first meeting and ask for the answers in writing. Short, specific answers are a good sign; vague ones are worth pressing on.

• Does every user get their own account, and how are roles set up?
• What does the audit trail record, and can ordinary users or administrators edit it?
• How long is it kept, and can I search and export it?
• What is backed up (database, uploaded files, settings and code)?
• How often, where are the copies kept, and for how long?
• When was a restore last tested, and can you run one before go-live?
• How long would it take to get us running again after a failure?
• How are passwords stored, and what stops repeated guessing?
• Is two-step verification available, for whom, and what is the lost-phone process?
• Where is the system hosted, in whose name, and is the connection encrypted?
• Who applies updates, and is that in the price?
• Who on your side can reach live data, and when is that access removed?
• What personal data does the system store, and how do we correct or delete it?
• What happens to my data and access if we part ways?

A due-diligence table: good answers and warning signs

Use this table when comparing builders or reviewing a proposal. It lists what a reasonable answer looks like, what should make you pause and what to ask to have written down.

If the builder claims an independent security certification or report, ask to see it and what it covers. Such documents describe a defined scope at a point in time; they do not prove that nothing can go wrong, and a small project does not always need one. Do not treat a missing certificate as an automatic failing either; judge the specific answers above.

What to put in the written quote

If a safeguard is not written down, you cannot assume it is included, and a missing one may later be treated as an extra. Ask for a short "security and recovery" section in the quote or specification that covers:

• Roles and logins. Individual accounts, the agreed roles, password rules and the scope of two-step verification.
• The audit trail. The events recorded, who can read it and how long entries are kept.
• Backups. What is copied, how often, where the copies are kept, how many are retained and who is responsible.
• The restore test. One before go-live, plus the agreed repeat rhythm, and who runs it.
• Hosting and updates. Where it runs, in whose name, who applies updates and whether that cost is included.
• Personal data. The fields stored, how a record is corrected or deleted and who to tell if something goes wrong.
• Access and exit. The builder's access to live data, when it ends, and how you get an export. See who owns the code for the related ownership questions.
• Acceptance. The tests that must pass before you pay the final milestone.

Put the same section in front of every supplier so the quotes can be compared like for like; how to compare custom software quotes shows how. To prepare for that first meeting, see what to prepare before you talk to a software developer. If you are moving existing records into the new system, the data migration guide covers keeping a safety net through cutover.

Common mistakes

• Assuming security is "included". Unless it is written in the quote, it may not be.
• Trusting a backup that has never been restored. Untested backups fail often enough to matter.
• Keeping backups only on the same server. A server failure then takes the data and the copy together.
• Sharing logins to save time. It destroys the audit trail and makes leavers hard to remove.
• Skipping two-step verification for administrators. They hold the keys to everything.
• Logging everything, or nothing. Pick the events that matter.
• Leaving personal data decisions to the developer. What you collect and keep is your business decision.
• Forgetting the end of the project. Builder access and old test copies need to be closed down.

Where Gotka Technologies fits

Gotka's App & System Development service builds mobile apps, web apps and business systems, from an indicative RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once your needs are scoped. This guide is general advice. It does not describe any specific security feature, backup arrangement or compliance status of a Gotka-built system, so, as with any supplier, ask for the points above to be stated in the written quote. Gotka's hosting plans list daily backups and free SSL as plan features; whether and how backups apply to a custom system is something to agree in the quote, not something this guide promises. The team is reachable through the contact page.

Key terms used in this guide

• Audit trail (audit log): an automatic record of who did what, to which record and when.
• Backup: a separate copy of data kept so it can be recovered if the original is lost or damaged.
• Restore test: putting a backup back into a separate test copy to prove it works and to time it.
• Two-step verification (2FA): a second proof, such as an app code, needed in addition to the password.
• Role: a set of permissions given to a type of user, such as owner, manager or staff.
• HTTPS: an encrypted connection between the browser and the system, shown by a padlock.
• Personal data: information that identifies a person, such as a name, phone number or identity card number.
• Retention period: how long a record or log entry is kept before it is removed.