New York audit readiness for operations and internal control teams

What to take away

What New York reviewers ask for first

New York holds the country's densest cluster of banks, insurers, and asset managers, alongside the Federal Reserve Bank of New York and the Department of Financial Services. Reviewers here open with the control environment, not the income statement.

The first request list names process owners, system access reviews, and the status of prior findings. 17(b). Map what you already hold against it using the checklist that catches what audits miss before you reply.

Read that list as a scope statement. If it names a process you have never documented, that is where the reviewer sees the most risk.

Interim testing and year-end fieldwork dates belong in writing. Work backward from them to set your own deadlines. Most engagements open six to eight weeks before fieldwork begins.

Control documentation that holds up

Control documentation records how a process should run and how you know it did: narratives, flowcharts, risk and control matrices, test results.

Internal audit samples transactions against the documented control. If the narrative says a manager approves invoices above a threshold, the sample must show that approval, dated, with the approver named.

Three failures recur. The narrative describes an ideal process rather than the real one. It carries no version control. It never names the control owner.

The operational risk assessment matrix ties each control to a specific risk, so the reviewer sees the logic rather than the paperwork.

For judgment-based controls, record the decision, the criteria applied, and the outcome. A reviewer who cannot see how a call was made will ask for the working papers.

Use one naming convention across every control document. Put the version and approval date on the first page. When a control changes, retire the old narrative rather than editing over it, and keep both so the sequence is visible.

A narrative last touched two years ago invites the question of whether anyone still follows it.

Change records that survive external review

A change record is the history of what changed in a system, process, or team, and why. Reviewers treat it as evidence that you manage risk rather than react to it.

Read change management with a sceptical eye here. Tools change. The four core documents remain the evidence reviewers accept:

Change records must agree with the incident log. Under 23 NYCRR 500.17(a), an entity covered by Part 500 must notify the Department of Financial Services of a qualifying cybersecurity event within 72 hours, so timestamps in both records have to line up.

A change advisory board, even one meeting weekly, puts approval evidence in one place. Log the business reason for each change, not only the technical description. Reviewers want to know who accepted the risk.

Emergency changes need retroactive approval inside a defined window, usually 24 to 48 hours. Reviewers look for that discipline specifically.

If your team cannot produce a record for a production fix made six months ago, assume the reviewer will ask.

Segregation of duties: the finding that repeats

Segregation of duties means no single person can both cause an error and conceal it. In New York financial and professional services operations, it is the control tested most often.

Small teams struggle here. A second reviewer or a system-enforced limit can stand in when true separation is not possible.

Map roles in your accounting and client systems to the tasks they permit, then compare that map against your control matrix. Most conflicts come from inherited access, not deliberate design. Firms that onboard quickly grant broad permissions and never narrow them.

In a market where a departing analyst can join a competitor a few blocks away, credentials often stay live long after the goodbye email. A quarterly access review catches that before a reviewer does.

Document any compensating control and test it. An undocumented workaround reads as a gap even when it works.

The naming the failure first method applies: identify the specific failure you are preventing, then design the control around it.

NIST guidance for system evidence

Operations teams lean on systems that reviewers treat as part of the control environment. The Cybersecurity and privacy | NIST guidance gives you a recognized structure for documenting those controls.

Use it to organize access control, logging, and incident response evidence. Reviewers know the framework and accept it as a benchmark.

For citable technical standards, the Publications | NIST library holds the specific documents you can reference in a control narrative. Access logs, administrator actions, and failed login attempts are the three records requested most often.

Other evidence sources

Three sources sit outside NIST and apply only where the work touches consumer data, breaches, or payroll. Use them alongside the framework, not instead of it.

If a breach occurs, the Data Breach Response: A Guide for Business | Federal Trade Commission outlines steps that also produce the evidence reviewers later request.

For operations handling consumer data, the Complying with COPPA: Frequently Asked Questions | Federal Trade Commission sets out expectations that feed into control design.

Payroll and related operations records follow the Publication 15-A (2026), Employer's Supplemental Tax Guide | Internal Revenue Service for supplemental tax documentation.

Building the evidence pack on a monthly cycle

An evidence pack is the organized set of documents supporting your control assertions. Build it monthly so nothing is more than 30 days old.

Run this before each external review cycle:

Decisions recorded during the cycle follow the what the written record actually needs standard: the decision, the criteria, the outcome.

Name every file so a reviewer can read the index without opening folders. Control number, period, owner. That pattern saves hours during fieldwork. Copy the index below and replace the placeholder rows with your own controls.

Common questions

What is an audit evidence pack?

It is the organized collection of documents proving your controls operated during the period: approvals, reconciliations, change records, test results. Index it so a reviewer can find each item without asking.

How often should control documentation be updated?

At least annually, and whenever a process, system, or owner changes. A narrative that no longer matches practice misleads the reviewer, which is worse than having none.

What if our New York team is too small for full segregation of duties?

Document compensating controls, such as a second reviewer or a system limit, and test them. Reviewers accept alternatives that are written down and evidenced.

How long should change records be kept?

Seven years is the figure most US examinations and client contracts settle on for change and approval records, and it is longer than many teams keep them. Access and administrator logs are usually kept 12 months, which covers one review period. Both are typical figures, and a client contract can set a longer term.