Cybersecurity for an Accounting App Stack

If your firm has added apps gradually and nobody can clearly explain who can access what, that is a common starting point. It does not mean every connection is unsafe. This guide will help you map the stack, identify the controls that matter and organise a practical security review without pretending that one checklist proves compliance.

The problem is the connection between the apps

An accounting app stack can include bookkeeping software, document storage, payroll, practice management, email, client portals, expense capture, reporting tools, automation services and AI features. Each product may look adequately protected when considered alone. The larger risk often sits between them: reused credentials, broad permissions, unattended integrations and unclear ownership.

Picture a practice owner reviewing the stack for the first time. Before the review, several staff use shared logins, multi-factor authentication is inconsistent and nobody has a record of which integrations still hold live access tokens. After the review, every person has an identifiable account, permissions match current duties, connections have named owners and the practice can explain how critical records would be restored.

This article concentrates on access, integrations, recovery and incident preparation. It does not determine whether client information should be disclosed to a particular AI provider, or whether a particular use complies with privacy, tax, employment or professional rules. Those questions need a separate data-use assessment and, where appropriate, advice for the relevant jurisdiction.

Why this matters to an accounting practice

Accounting systems hold information that can make fraud, impersonation and business disruption easier. Depending on the practice, the stack may contain identity records, bank details, payroll data, tax information, correspondence, signatures and documents used to authorise transactions.

A compromised account can therefore affect more than one app. An attacker who enters an email account may be able to reset passwords elsewhere. A captured integration token may continue moving data even after a user changes their password. A highly privileged account may allow changes to users, payment details or connected services.

Availability matters as well as confidentiality. A firm that cannot reach current records during a filing deadline or payroll run has an operational problem even if no information was publicly exposed. A sensible review therefore asks three questions:

1. Who can reach the information?
2. What can each person or connection do?
3. How would the firm keep operating and recover if access were lost?

What standards and regulators contribute

There is no single global cybersecurity rule for every accounting practice. Applicable requirements can depend on location, client type, services offered, contracts, professional obligations and the information being handled. Treat general frameworks as ways to organise the review, not as substitutes for jurisdiction-specific advice.

The European Union’s General Data Protection Regulation includes security-related provisions for organisations processing personal data within its scope. In the United States, the Federal Trade Commission publishes information about the Safeguards Rule, whose application to a particular accounting business should be confirmed rather than assumed.

The NIST Cybersecurity Framework offers a voluntary structure for understanding, governing, protecting, detecting, responding to and recovering from cybersecurity risk. ISO/IEC 27001 addresses information security management systems, while ISO/IEC 42001 addresses management systems for artificial intelligence. Certification is not the starting point for most small practices, but the management-system idea is useful: assign ownership, record decisions, check controls and improve them over time.

These sources do not produce a universal answer for your firm. Use them to frame questions, then confirm applicable obligations with relevant regulators, professional bodies, insurers, clients and qualified advisers.

Start with a map of the complete stack

You cannot review connections that nobody remembers. Begin with a simple register containing every app that creates, stores, receives or transmits accounting information.

For each app, record:

• its business purpose and named owner
• the administrator or administrators
• all current users, including contractors and external advisers
• whether multi-factor authentication is available and enabled
• the main types of information stored or processed
• connected apps, automation platforms and AI features
• the person responsible for reviewing each connection
• backup, export and restoration arrangements
• the renewal date and the process for closing the account

Do not rely only on subscription invoices. Check browser bookmarks, password-manager entries, finance records, staff interviews, email rules, marketplace installations and integration screens inside important applications. A free utility or trial can still have meaningful access.

Draw connections between systems, even if the result is a rough diagram. Mark which system sends information, which receives it and whether the connection can only read records or can also create, change or delete them. This makes hidden concentration visible, such as one automation account connecting email, document storage and the accounting ledger.

Fix identities before buying more security software

The strongest first move is usually better account discipline, not another security product. Each worker should have an identifiable account so activity can be attributed and access can be removed without disrupting everybody else.

Shared accounts make that harder. They obscure who performed an action, encourage password sharing and complicate offboarding. Where an application cannot support enough individual users, document the limitation, restrict the shared credential, name its custodian and consider whether that product remains suitable for sensitive work.

Enable multi-factor authentication wherever the relevant service supports it, prioritising email, identity providers, accounting platforms, payroll, document storage and administrator accounts. Multi-factor authentication adds another check beyond the password. It reduces reliance on a single secret, but it does not eliminate phishing, session theft or misuse by an authorised person.

Review password-reset routes at the same time. An administrator account protected by strong authentication can still be undermined if recovery messages go to an abandoned mailbox or a former employee’s phone. Record who controls recovery addresses, backup methods and emergency credentials.

For every privileged account, ask:

• Does this person need administrator access for routine work?
• Is there a separate account for administration where the platform permits it?
• Who receives security and login alerts?
• Can the firm recover the account if the usual administrator is unavailable?
• Is access reviewed after role changes, not only when somebody leaves?

Reduce permissions to what the work requires

Permission reviews are easier when they start with roles rather than individual names. List the work performed by partners, accountants, bookkeepers, payroll staff, administrators, contractors and external IT support. Then compare those duties with the access granted in each system.

Look for people who can export whole client lists, change bank details, invite users, alter security settings or delete records without needing those powers for their normal work. Also check whether temporary project access became permanent.

High-risk actions may justify a second person’s approval or a documented review, where the application and workflow allow it. Examples include changing payment instructions, adding administrators, modifying integration permissions and exporting large collections of records. This is a business control as much as a technical one.

Avoid treating the permissions screen as the whole answer. A person may gain equivalent access through an exported spreadsheet, synchronised folder, forwarded email or connected reporting tool. Follow the information, not just the application menu.

Inventory integrations and live access tokens

An integration token is a credential that lets one service communicate with another without asking a person to sign in every time. It may remain valid independently of the employee who originally created the connection. That makes integrations convenient, but easy to forget.

For every connection, record its owner, purpose, approved data flow, permission level and last review. Remove duplicate, abandoned and unexplained connections. If nobody can explain why an integration exists, pause it only after checking the operational impact and arranging a safe rollback path.

Pay particular attention to automation accounts and AI-connected services. Ask whether the connection can read only selected records or the full account, whether it can write changes back and where failures are reported. Review vendor documentation and current account settings directly before relying on any assumed capability.

Changing a staff password may not revoke every session, token, app password or delegated permission. Offboarding therefore needs a connection review as well as an account closure.

Make offboarding a same-day operational process

Terminated and transferred users are a predictable source of lingering access. Build one checklist that covers the entire stack rather than expecting each app owner to remember separate steps.

The checklist can include disabling the identity account, ending active sessions, removing application access, transferring ownership of files and automations, rotating shared credentials, reviewing integration tokens and recovering business devices. It should also cover contractors, seasonal staff and external bookkeepers.

Role changes deserve the same attention. Someone moving away from payroll or client administration may no longer need access even though they remain employed. Schedule a periodic comparison between the staff list and application user lists, with findings assigned to named owners.

Treat backups as a recovery capability

A successful status indicator is not the same as a proven recovery. For each critical system, establish what is backed up, who controls it, how long recovery might take and how restoration is tested.

Some cloud applications provide resilience for their own service without giving the customer a separate, point-in-time copy of all business records. Export and restoration options also vary. Confirm the current arrangements through vendor documentation, contracts and practical testing rather than assuming that a cloud subscription includes the recovery your practice needs.

Prioritise records required to continue essential work: current ledgers, payroll information, client contact details, engagement documents, work papers and the configuration information needed to rebuild important workflows. Keep recovery instructions somewhere accessible if the main identity or document system is unavailable.

Run a small restoration exercise. Select a non-sensitive sample, restore it to an isolated location and confirm that an authorised person can open and use it. Record what worked, what failed and how long the exercise took. Avoid testing restoration in a way that could overwrite live records.

Prepare for an incident before deciding whether it is a breach

A useful incident plan begins with observable events, not legal conclusions. Examples include an unfamiliar login, a fraudulent payment request, unexplained exports, a missing device, an integration sending unexpected data or a user locked out after an account change.

The first-response sheet should name:

1. who coordinates the response and who acts as backup
2. how staff report suspicious activity
3. how to contact important vendors, external IT support, insurers and advisers
4. how evidence such as alerts, timestamps and affected accounts will be preserved
5. who can suspend accounts or integrations
6. how the firm will operate while systems are unavailable
7. who assesses contractual, regulatory, client and law-enforcement notifications
8. how decisions and communications will be recorded

Do not promise secrecy to staff who report a mistake. Fast reporting is more useful than delayed certainty. Train people to report suspicious events without first having to prove that an incident occurred.

Containment decisions can have side effects. Deleting accounts, wiping devices or disconnecting an integration may remove evidence or interrupt essential work. Give the response coordinator authority to obtain technical and professional advice before taking irreversible action where circumstances permit.

Accounting-specific questions to include

Accounting firms should add workflow questions that a generic cybersecurity checklist may miss:

• Can one compromised account alter client bank or payment details?
• How are unusual requests to change payment instructions verified?
• Who can export tax, payroll or identity records in bulk?
• Do client portals and document links expire or remain accessible indefinitely?
• Can external advisers reach more clients or records than their engagement requires?
• Which deadlines would be affected if the ledger, payroll system or document store were unavailable?
• Are AI and automation connections included in the access register?
• Do engagement terms, client contracts or professional guidance affect the planned response?

The goal is not to declare the practice secure. It is to expose unanswered questions early enough for owners, advisers and service providers to resolve them.

A practical review sequence

Use this order to keep the project manageable:

1. Name an owner. Give one person responsibility for coordinating the review, while leaving system owners accountable for their applications.
2. Map the stack. List applications, users, administrators, integrations and critical information flows.
3. Secure identity. Replace avoidable shared access, enable multi-factor authentication and verify recovery methods.
4. Review permissions. Remove access that is excessive, unexplained or linked to an old role.
5. Inspect integrations. Identify tokens, delegated permissions, automation accounts and AI connections.
6. Reconcile workers. Compare every user list with current employees, contractors and advisers.
7. Test recovery. Confirm important information can be restored without damaging live systems.
8. Prepare the response sheet. Record contacts, authority, evidence steps and continuity arrangements.
9. Assign unresolved items. Give each gap an owner and review date rather than leaving it as a general concern.
10. Repeat the review. Recheck after staffing changes, major integrations, security incidents and significant changes to the stack.

A spreadsheet may be enough for a small practice. The quality of ownership and follow-through matters more than buying a complex governance platform the team will not maintain.

Related reading: our AI governance by region.

Related reading: Best Accounting Practice Management Software and Best AI Bookkeeping Automation Tools.

Does every accounting app need multi-factor authentication?

Prioritise multi-factor authentication for every service that supports it, especially email, administrator accounts and systems holding financial or identity information. Where a critical service lacks suitable controls, document the limitation and assess compensating measures or alternative products with qualified technical advice.

Is a password manager enough to stop shared accounts?

No. A password manager can control storage and sharing, but it does not create individual accountability inside an application. Use named accounts where possible, then reserve controlled shared credentials for documented exceptions.

Does changing an employee’s password remove integration access?

Not necessarily. Sessions, delegated permissions, app passwords and integration tokens may be managed separately. The offboarding process should review and revoke each form of access using the application’s current documentation.

Are cloud accounting records automatically backed up?

Do not assume the provider’s service resilience gives your firm the export, retention and restoration capability it expects. Confirm what the provider covers, what remains the customer’s responsibility and whether a practical restoration test is possible.

How often should the stack be reviewed?

Use a regular schedule suited to the firm’s risk and rate of change, then trigger additional reviews after departures, role changes, new integrations and security incidents. Applicable contracts, professional guidance or local rules may influence the appropriate frequency.

Does this checklist make an accounting practice compliant?

No. It is a general planning tool for organising a cybersecurity review. Compliance depends on the firm’s jurisdiction, services, clients, contracts, professional duties and actual implementation, so material questions should be checked with relevant authorities and qualified advisers.

Methodology

This guide applies the Navigator Model: explain the issue, identify authoritative sources and provide a practical way to organise decisions without interpreting the law for a particular firm. Before publication, an editor should verify all regulatory references against current primary sources and review the checklist with accounting cybersecurity and professional-obligations specialists.

Take the next step

Turn the review sequence into a named action list for your practice. Start with email, the primary accounting platform and document storage, then follow their connections outward until every account, integration and recovery process has an owner.

Explore more practical compliance and governance guides