Cybersecurity Controls over Financial Processes

Does anyone inside the business hold credentials that can move money or change the accounting records - banking portal logins, payment or payroll initiation rights, or administrative access to the general ledger?

This question scopes the whole review. If insiders hold credentials that can move funds or alter the ledger, the access, segregation, verification, and recovery controls below are yours to design and operate. If everything is executed by providers, the control work changes character: it becomes provider assurance, contractual obligations, and entity-level verification of what the providers did. The common trap is a forgotten credential - an old bank token or a dormant administrator login kept 'just in case' - which quietly puts the entity back in the first category.

Management remains responsible for processes performed by external parties - shift the control work to provider oversight and independent verification (Green Book, Principle 11).

Official guidance: GAO Standards for Internal Control

How is user access to the general ledger and to banking and payroll portals granted, maintained, and removed?

Access management is the foundation the other financial controls stand on: every payment release, journal entry, and master-file change must trace to one accountable individual. Answer from the system-generated user listings, not from memory. If you chose the second option, the review continues, but carry the missing recertification forward as a documented finding - stale access is how departed employees and role creep quietly become payment risk.

Framework reference for the control activities component, including Principle 11 on general control activities over technology.

Official guidance: GAO Standards for Internal Control

• COSO Internal Control - Integrated Framework

Is multi-factor authentication enforced - not merely available - on the banking portal, the payroll system, remote and administrator access to the ledger, and the email accounts of everyone who can approve payments?

Test the claim, not the setting: log in from a new device and observe what is actually demanded. The recurring traps are legacy email protocols that bypass MFA, 'remember this device' horizons measured in months, and exemptions granted to the very executives whose mailboxes attackers target to approve payments. Approver email belongs on this list because a compromised mailbox is how payment instructions get forged and intercepted.

A password-only banking portal or approver mailbox is the most common entry point for payment fraud - enforce multi-factor authentication before relying on any downstream control (Green Book, Principle 11).

Official guidance: GAO Standards for Internal Control

Can any one person - including an owner or the bookkeeper - both create or change a vendor's payment details and approve or release a payment to that vendor, with no second person required?

Judge this on system rights, not job descriptions - portal administrator roles often carry both powers even when the daily routine splits them, and the answer is 'yes' if the rights coexist in one login. In small teams where full separation is impractical, the standard compensating controls are bank-enforced dual release on wires and ACH plus an owner's independent review of the payee-change report each cycle.

One person who can change payee details and release funds is an unmitigated fraud path - impose dual control at the bank-portal level now (Green Book, Principle 10).

Official guidance: GAO Standards for Internal Control

When a vendor, employee, or lender asks to change bank account details or sends new payment instructions, how is the request verified before anything is updated or paid?

Business email compromise works by hijacking or imitating a genuine correspondence thread, so any verification that travels through the requesting channel is circular - the attacker controls both the request and the confirmation. The control that works is deliberately boring: an out-of-band call to a number the entity already held, documented on the change form, with no exceptions for urgent, executive-sponsored, or end-of-quarter requests. If you rely on portal automation alone, add the human callback for payees above a value threshold.

Confirming a bank change through the channel that requested it is the exact failure business email compromise exploits - adopt out-of-band callback verification (Green Book, Principle 8). Unverified payee changes are the leading mechanism of vendor impersonation fraud - stand up a documented callback procedure before the next change request arrives (Green Book, Principle 8).

Official guidance: GAO Standards for Internal Control

If a fraudulent payment went out this morning, is there a written same-day response the team could execute - who calls the bank to attempt recall, who files the law-enforcement complaint, who preserves the emails and approvals - and have finance staff been trained on payment-fraud red flags within the past year?

Recovery prospects for a fraudulent wire or ACH fall sharply after the first hours, so the response has to be written, named, and rehearsed before it is needed - during an incident is too late to look up the bank's fraud desk. Training matters because the human is the control surface: the red flags are urgency, changed remittance details, new bank instructions, and pressure invoking an executive's name, and staff who have seen the pattern once in training recognize it in the inbox.

Recall windows for fraudulent transfers are measured in hours - a written same-day response and trained staff are part of the control, not an afterthought (Green Book, Principle 12).

Official guidance: GAO Standards for Internal Control

Are the accounting system and supporting financial records backed up automatically to a copy that a compromised administrator account could not alter or delete, and has a restore actually been tested within the past year?

Ransomware operators deliberately hunt backups using the same stolen administrator credentials that took production, so 'we have backups' only counts if at least one copy sits beyond those credentials - offline, immutable, or under separate authentication - and a restore has been rehearsed end to end. For cloud accounting platforms, learn what the provider's resilience actually guarantees and what remains yours to export and protect, such as attachments, configurations, and integrations.

An untested backup reachable with production credentials is not a control - segregate the copy and prove the restore (Green Book, Principle 11).

Official guidance: GAO Standards for Internal Control

If an employee notices a suspicious login, phishing email, or unexpected payment, do they know exactly whom to tell, and does the escalation path reach finance leadership and the bank - not just the IT support channel?

A financial incident is two responses in one: the technical containment, and the money response - the bank recall call, payment holds, ledger correction, and insurer notification. Both begin with an employee speaking up fast, which is why a blame-free, widely known reporting path is itself an internal control. The test is simple: ask three employees today whom they would tell about a suspicious email, and see whether the answers match the procedure.

The core control set is designed and operating - shift effort to monitoring, periodic testing, and reassessment (Green Book, Principle 16). Escalation that stops at the helpdesk leaves the bank recall, payment holds, and the ledger impact unmanaged - publish a path that reaches finance leadership (Green Book, Principle 14).

Official guidance: GAO Standards for Internal Control