How Investment Firms Should Prepare for Cyber Incidents
By Rachel Blum, Director of Information Security Services, and Jonathan Lemon-Fears, Cyber Security Services Manager, RFA
By Rachel Blum, Director of Information Security Services, and Jonathan Lemon-Fears, Cyber Security Services Manager, RFA
Last week, attackers used a stolen credential from ConnectWise Cloud Backup to gain access to Microsoft 365 environments. Following the breach, the attackers attempted sign-ins to more than 2,250 tenants at 2,900 attempts per minute. Cyberattacks are getting faster and harder to detect. Attackers can now use agentic AI to scan exposed systems and test stolen credentials across thousands of targets at once. Security strategies focused exclusively on internal networks, endpoints, and user accounts are no longer sufficient. Organizations must also account for the risks introduced by third-party providers, cloud integrations, and privileged access across their environments, and must extend their security assessment and protocols to their providers. This article covers vendor access and oversight and cyber incident response plans.
Quick answer: Investment firms should give each vendor only the system access its service requires and monitor vendor account activity. Firms should also agree in writing with their providers on who handles each part of an incident, and test the plan with tabletop exercises. Under amended Regulation S-P, SEC-registered advisers need a written incident response program, must notify affected individuals within 30 days of becoming aware of a breach, and need procedures for service providers to report breaches within 72 hours. Firms should also prepare tested backups, cyber insurance, legal counsel, and draft investor notices ahead of time, so a response can start right away if an incident occurs.
Software providers, cloud services, and other third parties need access to firm systems to work, and every vendor with system access expands the firm's attack surface. If attackers compromise a vendor's credentials or application access, they may be able to exploit that trusted relationship to gain unauthorized access to connected customer environments, depending on the permissions and security controls in place.
This is what happened with the ConnectWise breach. Attackers stole a credential for the Microsoft 365 backup application and used it to sign in to customer environments as the application itself. Huntress, the security firm that tracked the activity, confirmed unauthorized sign-ins in 173 partner and customer tenants.
At RFA, our threat intelligence and security feeds flagged a potential issue before ConnectWise made a formal announcement. As a precautionary measure, we proactively restricted the affected application's access across client environments while evaluating potential exposure and monitoring for indicators of compromise. When ConnectWise began publishing indicators of compromise, we scanned every client environment against the list continuously over a few days as new information became available. We ultimately did not find anything and will be restoring access in phases as ConnectWise confirms it is safe to do so.
Firms should give each vendor only the access its service requires, monitor vendor account activity, and flag activity outside the normal pattern. Firms should also decide in advance who has the authority to cut off vendor access during an incident, and confirm in writing with their provider. In the ConnectWise case, the decision to restrict the application was taken as a precautionary measure based on threat intelligence before the vendor had publicly confirmed the incident.
Good vendor oversight starts with due diligence at the beginning of the relationship, paired with ongoing monitoring. The depth and frequency of review should scale with the systems and data the vendor can access, so providers with direct system access or sensitive data get the most thorough and frequent attention.
If a vendor suffers an incident that affects your data, the contract should specify a notification period that allows you to meet your obligations, whether those come from Regulation S-P, from GDPR or UK GDPR for European or UK data, or from investors. A vendor that reports a breach too late can put you out of compliance before you are able to respond.
The second item to define is a clear, unambiguous division of responsibilities between the firm and the provider. One common format is a RACI matrix, a simple chart showing who is responsible, accountable, consulted, and informed for each task. During an incident, the Incident Response Plan should define who contacts the affected vendor, decides to shut off a service, speaks to investors, and files with regulators. While organizations cannot anticipate every incident scenario, contracts and response procedures should clearly establish decision-making authority, escalation responsibilities, and communication expectations between the firm and its service providers.
During an incident, you should receive prompt notice from your vendors, a summary of their findings, and regular updates while they investigate. You should confirm each vendor's process for sharing updates as part of your due diligence. You should also have a plan for keeping the business running when a vendor's service is unavailable, including backups and an alternative way to work while the affected tool is offline. If you work with a managed IT and security provider, agree on its role in coordinating with your vendors during an incident.
Responding to an incident has two parts: the technical response and the business response. Effective incident response requires coordination between technical teams, service providers, and business leadership. Technology and security partners may lead or support investigation, containment, and recovery activities, while the firm retains responsibility for business decisions, regulatory obligations, investor communications, and operational continuity. These responsibilities should be clearly defined and understood before an incident occurs.
The Incident Response Plan should outline who can approve major decisions, such as taking systems offline, engaging counsel and communicating with key counterparties. It should list the communication channels to use if email is down, and the steps for sending a message to investors and vendors.
Have the following ready in advance: cyber insurance and the steps to activate it, legal counsel you can call during an incident, approved templates for investor notices, and a list of the regulators and counterparties you must notify. Firms without insurance, or firms that did not notify their insurer promptly, can pay far more after an incident than the policy would have cost.
The next step is to ensure the plan works in practice. Run tabletop exercises with the people who would be involved in a real incident, and repeat them on a regular schedule. In our experience, staff who have practiced their roles are more comfortable when a real incident happens.
Two attacks on medical device companies this year shut down large parts of their operations. In March, a group got into Stryker's administrator accounts and used the company's own device management system to remotely wipe employee laptops and phones. In August, an attack on Boston Scientific caused a network outage that disrupted manufacturing and the processing and shipment of orders, and the company later said it no longer expected to meet its 2026 sales and profit forecasts.
Plan for continued operations and recovery when a critical system is unavailable. Start with your operational dependencies: where communications run, where client and investor information is held, and which systems your teams cannot work without.
Organizations should know where backups are stored, how frequently they are performed, and which personnel are responsible for restoring critical systems and information. Run disaster recovery tests regularly and confirm the most recent ones were successful. Keep the recovery plan in writing, and ensure people assigned to it are trained and available. When we have seen firms stall during recovery, it was typically because they did not plan in advance. As a Managed Security Provider, we identify gaps in recovery planning and map them out with the client to build a custom recovery plan.
COOs and CCOs should be directly involved in the firm's security program. A provider can supply plans, tools, and monitoring, but the firm has to understand its own critical systems and data. Start with an inventory of your infrastructure, and classify your data by sensitivity so the most important data gets the most protection.
Once the critical systems are identified, the next step is keeping them maintained. Monitoring alone does not keep an environment secure. Firms should work with their IT partners to review configurations on a routine schedule, remove access for former staff and vendors, and set network controls to allow only the traffic the firm needs. Where possible, block unwanted activity with a control rather than relying on monitoring to catch it afterward.
To determine whether security controls are operating effectively, firms should prioritize evidence-based assessments over self-reported compliance questionnaires. This includes reviewing actual system configurations, monitoring results, access controls, and documented incident response exercises. A questionnaire asks the firm to describe its password policy, while an evidence-based assessment pulls the actual configuration or the report from the last incident response tabletop. In RFA's governance, risk, and compliance program, each control in a recognized framework is checked on a weekly, monthly, or quarterly schedule, so the annual report reflects a full year of checks.
The same evidence answers what regulators and investors ask for. A prepared firm can show which vendors have access to which systems, who is responsible for each part of an incident response, and the results of its backup and notification tests.
As cyber threats continue to evolve, investment firms must look beyond traditional prevention and focus on building security programs that can adapt, respond, and recover.
Effective cybersecurity requires a combination of strong foundational controls, continuous monitoring, clear accountability, and regularly tested response procedures. Organizations should understand not only where their risks exist, but also how those risks could affect critical business operations.
Ultimately, the firms best positioned to manage cybersecurity threats will be those that treat security as an ongoing business responsibility rather than simply a technology investment.
At least once a year, and again whenever the firm changes a major system, provider, or member of its leadership team. The exercise should include the people who would make business decisions during an incident, such as the COO, CCO, and investor relations, not only technical staff. A written report from each tabletop is also useful evidence for regulators and investors that the incident response program is tested.
In our experience, yes. We have seen firms without coverage pay investigation, legal, and recovery costs on their own after an incident. A policy is only useful if the firm can activate it quickly, so the notification requirements and the insurer's contact process should be written into the incident response plan.
Start by comparing each vendor's permissions with the service it actually provides. Administrator rights, access to systems the vendor does not support, and accounts for services the firm no longer uses are all signs of excess access. Review vendor permissions at onboarding, on a regular schedule, and whenever the scope of the service changes. Where possible, replace standing access with access that is granted only when the vendor needs it.
Restrict the vendor's access to your environment as a precaution while you assess potential exposure. Activate your Incident Response Plan so the people responsible for technical, legal, and investor decisions are informed. Ask the vendor for indicators of compromise, scan your systems against them, and keep checking as the vendor releases new information. Work with legal counsel to confirm your notification obligations, and document each decision and its timing.
Speak with an RFA advisor about IT, cybersecurity,
AI, and compliance for financial services.