Risk & Compliance

Enterprise risk, regulatory compliance, third-party risk, and internal controls built to be tested.

The audience for this page is the organization that will be examined — by a regulator, by a federal awarding agency, by a tax authority, by an insurer after an incident. We design the program so the evidence exists before anyone asks for it.

An ERM framework that cannot name the ten risks the board actually owns is a binder. We build a register tied to the organization’s real exposures: grant noncompliance and questioned costs, a regulatory examination, a vendor that holds production data, a single person who can move funds, a facility that cannot run if the office is closed.

Each risk gets an owner, an existing control, a residual-risk rating, and a decision — accept, mitigate, transfer, or avoid — that a committee can record. We do not import a 200-row bank template into a fifty-person organization and call it maturity.

The test of the framework is whether it changes a budget or a vendor decision. If it does not, it is not enterprise risk management.

01Regulatory compliance

We map the regimes you actually answer to, then build the calendar and the file that go with them.

For an examined financial-services business, that is the cybersecurity program, the CISO’s report to the board, the annual certification, and a notification clock that starts the moment something is discovered.

For nonprofits with federal awards, it is the federal award rules, the schedules, and the single audit. For tax-exempt organizations, it is the annual return — and the standing that depends on filing it — including, in Puerto Rico, standing with Hacienda.

Compliance work that does not produce a dated obligation list, an owner, and evidence is reporting, not a program.

02Third-party risk management

Your vendors hold your data, and your regulator holds you responsible for it. We build third-party risk programs that inventory who has access to what, tier vendors by actual exposure rather than contract value, set assessment requirements proportional to that tier, and embed security obligations in the contract itself — so the requirement survives the renewal.

Where the rules reach you, a written third-party policy, real due diligence, and periodic reassessment are not optional. A spreadsheet of names with last year’s SOC report attached — unread — will not satisfy that. We define what “periodic” means for each tier, what finding closes a contract, and what finding does not.

For nonprofit and grant-funded organizations the same structure applies to subrecipients and to the SaaS tools that hold donor or beneficiary data. The vocabulary changes. The exposure does not.

03Privacy and data protection

Privacy work starts with an inventory: what you collect, where it lives, who can see it, how long you keep it, and what notice you owe if it leaves. We build that inventory, the retention and disposal schedule, and the decision tree for incident notice across the jurisdictions you actually operate in.

This is the same discipline we apply to our own site: say what you collect, do not describe a comment system you do not have, and do not claim a safeguard you cannot defend. If a regulator or a counterparty asks for the program, the documents should already exist.

The annual information return asks governance and related-party questions that often surface the same records a privacy review needs — who has access, who is paid, what is disclosed. We treat those as one evidence set, not two projects.

04Business continuity and disaster recovery

A continuity plan that has never been run is a hope. We define critical functions, recovery-time and recovery-point objectives, alternate processing, and the people who have the authority to declare an event.

Then we test it. A tabletop is the minimum; a restored backup that someone has actually logged into is better. Regulators that address continuity expect a plan that has actually been tested. We write to that standard even where no regulator requires it, because untested plans fail the same way everywhere.

The plan names vendors that would have to fail with you — payroll, core banking, electronic health or donor systems — and what you do if they do.

05Internal control design and testing

Controls are designed for the team you have. A three-person finance office will not have textbook segregation of duties; it can have compensating review, dual authorization on disbursements, and a bank reconciliation someone other than the preparer signs.

We write the control, we name the evidence it should produce, and we test it. The workpapers are the point. A narrative without a sample will not survive a single audit, a regulatory examination, or a governance review that turns into questions about who can move money.

When a control fails, we say whether the failure is design or operation, and what it costs to fix. We do not bury a fail in a “management comment.”

06Related Insights

23 NYCRR 500 Cybersecurity Requirements (January 17, 2018). FinCEN BOI (August 19, 2026). EO 14409 (June 16, 2026).