A security incident at an accounting firm creates two separate challenges: responding to the technical problem and determining what the incident means for the firm's regulatory and business responsibilities.
For accounting firms covered by the GLBA Safeguards Rule, incident response is part of the firm's broader information security program. That means the firm needs more than a plan for restoring systems. It needs a process for investigating what happened, determining what information was affected, evaluating whether a regulatory notification threshold has been met, communicating appropriately, and documenting the response.
The Federal Trade Commission's Safeguards Rule requires covered financial institutions to notify the FTC as soon as possible, and no later than 30 days after discovering a qualifying notification event involving at least 500 consumers' unencrypted information. The rule's definition of a notification event is specific, so not every security incident requires FTC notification.
For an accounting firm, the response should follow a defined process:
Incident → Investigation → Determine whether notification threshold is met → FTC notification, if required → Client communication → Remediation → Documentation
The goal is not simply to respond quickly. It is to respond in a way that reduces risk, preserves evidence, supports informed decisions, and improves the firm's security program afterward.
The GLBA Safeguards Rule requires covered financial institutions under FTC jurisdiction to maintain an information security program designed to protect customer information. The FTC's definition of a financial institution is broader than banks and traditional financial services companies and includes tax preparation firms among the examples of potentially covered businesses. Whether a particular accounting firm is covered depends on its activities and applicable regulatory jurisdiction.
A security incident can take many forms, including:
Not every incident meets the GLBA definition of a notification event.
That distinction matters. The firm's first responsibility is to investigate the incident and establish the facts.
A practical GLBA incident response process should move through seven stages.
Each stage should have defined responsibilities, decision points, and evidence.
The first priority is to establish control of the situation.
Depending on the incident, containment could include:
For Microsoft 365 environments, identity should be an immediate area of investigation. A compromised account may provide access to email, SharePoint, OneDrive, Teams, customer records, and connected applications.
The objective at this stage is not to determine every detail. It is to prevent the incident from continuing while preserving information needed for the investigation.
Useful incident response metrics include:
Once the immediate threat is contained, the firm needs to determine what actually occurred.
The investigation should establish:
This is where security monitoring and logging become particularly important.
Without sufficient logs, an organization may know that an account was compromised but struggle to determine what the account accessed or whether customer information was acquired.
For Microsoft 365 environments, relevant evidence can include identity sign-in activity, authentication events, administrative activity, email activity, endpoint alerts, cloud application activity, and access to SharePoint or OneDrive resources.
Incident response should also include appropriate evidence preservation.
Depending on the circumstances, that may include:
Legal counsel or qualified incident response professionals should help determine appropriate evidence preservation and investigative procedures for a specific event.
The next question is not simply "Were we breached?"
The more useful questions are:
What information was involved?
Whose information was involved?
Was the information accessed or acquired without authorization?
Was the information encrypted?
How many consumers may be affected?
The Safeguards Rule defines customer information as records containing nonpublic personal information about a customer of a financial institution, whether in paper, electronic, or other form, that is handled or maintained by or on behalf of the organization.
For an accounting firm, that could include information contained in:
A firm's data inventory should make this process easier. If the firm does not know where customer information resides before an incident, determining the scope of an incident becomes significantly more difficult.
Create a record of:
This is one of the most important decision points in a GLBA incident response process.
The Safeguards Rule requires covered financial institutions to notify the FTC of a notification event as soon as possible and no later than 30 days after discovery.
The notification requirement applies when the event involves the unauthorized acquisition of unencrypted customer information affecting at least 500 consumers. The rule also addresses situations involving encrypted information where the encryption key was accessed by an unauthorized person.
The FTC describes the requirement as applying to a security breach involving the unauthorized acquisition of at least 500 consumers' unencrypted information.
That means a security incident should not automatically be treated as an FTC-reportable event.
The firm should instead evaluate the specific facts against the rule.
The 30-day period is tied to discovery of the notification event. Because determining whether an event meets the threshold can involve technical, legal, and factual questions, firms should involve appropriate legal or compliance professionals when evaluating a specific incident.
If the incident meets the Safeguards Rule's notification-event definition, the covered financial institution must notify the FTC as soon as possible and no later than 30 days after discovery.
The FTC provides an online Safeguards Rule security event reporting form for covered financial institutions. The form requests information such as the date range of the event, number of consumers affected or potentially affected, types of information involved, and a summary of the event.
The FTC notes that a third party, such as an attorney or service provider, may submit a report on behalf of an affected financial institution.
The firm's incident response process should therefore establish in advance:
This is a governance issue as much as a technical one.
FTC notification is only one potential communication requirement.
Depending on the incident, the firm may also have obligations arising from:
These requirements vary based on the circumstances and jurisdiction.
The incident response plan should therefore identify who is responsible for evaluating notification obligations rather than leaving that decision to the IT team alone.
When communicating with an affected client, the firm should be prepared to explain:
The objective is to communicate verified information without speculating about facts that have not yet been established.
Incident response does not end when the immediate threat is contained.
The firm should determine why the incident was possible and whether the underlying control weakness exists elsewhere.
For example:
Compromised Microsoft 365 account
Potential remediation:
Ransomware incident
Potential remediation:
Unauthorized access to cloud files
Potential remediation:
The goal is to address the control failure, not simply restore the affected system.
Backup is an important part of incident response, but having backups is not the same as having a reliable recovery capability.
After an incident, the firm should determine:
For accounting firms, recovery priorities should be tied to business operations.
Critical systems may include:
Recovery objectives should be documented before an incident occurs, not determined for the first time while systems are unavailable.
Documentation is part of effective incident response.
The incident record should capture:
Documentation provides evidence of how the firm responded and creates a record that can be used to improve the security program.
It can also help leadership identify recurring weaknesses.
For example, if multiple incidents involve compromised credentials, the broader security program may need to address identity security, MFA coverage, privileged access, employee behavior, or authentication policies.
The final stage is turning the incident into measurable improvement.
A post-incident review should ask:
Was the issue related to identity, endpoint security, email, configuration, monitoring, backup, employee behavior, vendor access, or another control?
Was it missing, incorrectly configured, bypassed, poorly monitored, or not consistently maintained?
Review the available security telemetry and determine whether the organization had the necessary visibility.
Consider whether stronger access controls, better segmentation, improved backup isolation, or faster response could have reduced the scope.
Assign remediation actions to specific owners with deadlines and measurable outcomes.
A useful post-incident action plan looks like:
Finding → Risk → Corrective action → Owner → Deadline → Evidence of completion
This turns an incident from a standalone event into an input for the firm's ongoing security program.
The Safeguards Rule requires covered financial institutions to maintain a written incident response plan designed to address security events affecting the confidentiality, integrity, or availability of customer information. The FTC includes incident response among the elements of the required information security program.
At a minimum, an accounting firm's plan should define:
The plan should also identify external resources that may be needed during an incident, such as legal counsel, digital forensics, cyber insurance contacts, managed security providers, and specialized incident response firms.
For accounting firms using Microsoft 365, identity and cloud security can be central to incident detection and response.
A compromised Microsoft 365 identity can potentially provide access to email, files, collaboration tools, and connected applications. That makes identity activity an important source of incident evidence.
A security review should consider:
The objective is not to enable every security feature available. It is to establish whether the controls appropriate to the firm's documented risks are configured correctly, monitored consistently, and supported by an incident response process.
An IT or managed security provider may play a significant role in detecting, containing, investigating, and recovering from an incident. But the provider should have clearly defined responsibilities before an incident occurs.
Accounting firms should be able to answer:
The IT provider should support the firm's information security program, not create ambiguity about who owns decisions.
This is especially important when multiple providers are involved across Microsoft 365, endpoints, backup, line-of-business applications, and security monitoring.
Incident response should be measured like any other operational process.
Useful metrics include:
| Metric | What it tells leadership |
|---|---|
| Mean time to detect | How quickly the organization identifies potential incidents |
| Mean time to investigate | How quickly alerts become understood events |
| Mean time to contain | How quickly the organization limits the incident |
| Mean time to recover | How quickly critical operations are restored |
| Incidents by root cause | Where recurring weaknesses exist |
| High-severity incidents | How often material security events occur |
| Repeat incidents | Whether remediation is addressing underlying causes |
| Backup recovery test success | Whether recovery capabilities work as expected |
| Incident response exercise completion | Whether the response process is being practiced |
| Open remediation actions | Whether lessons from incidents are being addressed |
The value of these metrics is not the number itself. It is the behavior they drive.
If containment time is consistently high, investigate why.
If the same type of incident keeps recurring, address the underlying control.
If recovery testing repeatedly identifies gaps, prioritize those gaps before an actual disruption occurs.
A GLBA security incident should not be managed as an improvised technical emergency.
The firm's response should follow a repeatable process:
Detect → Contain → Investigate → Assess → Notify → Recover → Remediate → Improve
That process connects the technical response to the firm's regulatory responsibilities and broader security program.
For accounting firms, the most important preparation happens before an incident:
The FTC's Safeguards Rule is designed around maintaining an ongoing information security program, not responding to a single event after it occurs.
A well-designed incident response process gives leadership a practical way to move from incident → facts → decisions → remediation → measurable improvement.
Yes. Covered financial institutions subject to the FTC Safeguards Rule must maintain a written incident response plan designed to address security events affecting the confidentiality, integrity, or availability of customer information.
The firm should contain the incident, investigate what happened, determine what customer information was affected, evaluate whether the event meets the GLBA notification threshold, complete required notifications, communicate with affected parties as appropriate, recover systems, remediate security weaknesses, and document the response.
A covered financial institution must notify the FTC as soon as possible and no later than 30 days after discovery of a notification event involving the unauthorized acquisition of unencrypted customer information affecting at least 500 consumers. The Safeguards Rule contains specific definitions and requirements, so not every security incident requires FTC notification.
No. The GLBA Safeguards Rule's FTC notification requirement applies to a specific type of notification event. The event must involve unauthorized acquisition of unencrypted customer information affecting at least 500 consumers, subject to the rule's specific requirements. Firms should evaluate the facts of an incident with appropriate legal or compliance professionals.
The firm should determine which systems, accounts, applications, and data were involved; whether customer information was accessed or acquired; what types of information were involved; how many consumers may be affected; whether the information was encrypted; and when the relevant event was discovered.
A GLBA incident response plan should define roles, escalation procedures, containment, investigation, evidence preservation, customer information assessment, legal and regulatory review, notification procedures, client communications, recovery, documentation, and post-incident remediation.
Microsoft 365 can provide security and audit capabilities relevant to incident detection and investigation, including identity activity, MFA, administrative activity, email security, cloud access, endpoint security, and logging. The effectiveness of those capabilities depends on how they are configured, monitored, and incorporated into the firm's broader information security program.
The IT provider may be responsible for monitoring, investigation, containment, recovery, and technical remediation depending on the firm's agreement with the provider. Responsibilities should be defined before an incident, including who escalates the event, preserves evidence, coordinates with legal counsel, evaluates notification requirements, and communicates with leadership.
The firm can use tabletop exercises, technical recovery exercises, phishing scenarios, compromised-account simulations, and backup restoration tests. Each exercise should produce documented findings, assigned remediation owners, deadlines, and evidence that corrective actions were completed.
There is no single investigation timeline that applies to every incident. The Safeguards Rule requires FTC notification as soon as possible and no later than 30 days after discovery of a qualifying notification event. Firms therefore need an incident response process capable of rapidly establishing the facts needed to evaluate whether the notification threshold has been met.
GLBA's FTC notification requirement is distinct from other potential notification obligations. Depending on the incident, applicable state laws, contracts, professional requirements, insurance requirements, or other regulations may impose additional obligations. The firm should evaluate those requirements with appropriate legal or compliance professionals.
Establish a documented, tested incident response process before an incident occurs. The firm should know what customer information it holds, where that information resides, who can access it, how security events are detected, who owns response decisions, how regulatory obligations will be evaluated, and how systems will be recovered.