GLBA Security Incident Response for Accounting Firms | Sourcepass

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.

What Is a GLBA Security Incident?

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:

• A compromised Microsoft 365 account
• Unauthorized access to customer files
• A phishing attack that results in credential theft
• Malware or ransomware affecting systems containing customer information
• Unauthorized access to SharePoint or OneDrive
• A lost or stolen device containing customer information
• A compromised third-party accounting or tax application
• An employee accidentally sending sensitive information to the wrong recipient
• A security event involving a service provider with access to customer information

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.

What Happens After a GLBA Security Incident?

A practical GLBA incident response process should move through seven stages.

1. Identify and contain the incident
2. Investigate what happened
3. Determine what information was affected
4. Evaluate whether the GLBA notification threshold is met
5. Complete required notifications and communications
6. Remediate the underlying security weaknesses
7. Document the incident and improve the security program

Each stage should have defined responsibilities, decision points, and evidence.

1. Identify and Contain the Incident

The first priority is to establish control of the situation.

Depending on the incident, containment could include:

• Disabling a compromised user account
• Resetting credentials
• Revoking active sessions
• Isolating an affected endpoint
• Blocking malicious email or domains
• Restricting access to affected files
• Disabling a compromised application integration
• Protecting backup systems from further access
• Engaging an incident response or security operations team

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.

What to measure

Useful incident response metrics include:

• Time from alert to investigation
• Time from investigation to containment
• Number of affected accounts or devices
• Number of systems isolated
• Number of active sessions revoked
• Time to restore secure access

2. Investigate What Happened

Once the immediate threat is contained, the firm needs to determine what actually occurred.

The investigation should establish:

• How the incident started
• When suspicious activity began
• Which accounts or systems were involved
• Whether unauthorized access occurred
• Whether information was accessed, acquired, changed, deleted, or encrypted
• Which customer records may have been involved
• Whether the attacker retained access
• Whether a third-party provider was involved

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.

Preserve evidence

Incident response should also include appropriate evidence preservation.

Depending on the circumstances, that may include:

• Authentication logs
• Endpoint data
• Email records
• Cloud audit logs
• File access records
• Security alerts
• Firewall or network logs
• Backup information
• Relevant communications
• Incident response notes

Legal counsel or qualified incident response professionals should help determine appropriate evidence preservation and investigative procedures for a specific event.

3. Determine What Customer Information Was Affected

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:

• Tax returns
• Financial statements
• Banking information
• Account information
• Payroll records
• Identity information
• Financial documents
• Email correspondence
• Client portals
• Cloud document repositories
• Tax and accounting applications

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.

What to document

Create a record of:

• Systems affected
• Types of information involved
• Number of potentially affected consumers
• Whether the information was encrypted
• Accounts involved
• Third parties involved
• Evidence supporting the determination

4. Determine Whether the GLBA Notification Threshold Is Met

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.

Questions to ask

• Was customer information involved?
• Was the information unencrypted?
• Was there unauthorized acquisition?
• How many consumers were affected or potentially affected?
• Was an encryption key accessed?
• When was the notification event discovered?
• Does the event meet the regulatory definition?
• Are there other federal, state, contractual, or professional obligations that also apply?

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.

5. Complete Required FTC Notification

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:

• Who determines whether notification is required
• Who works with legal counsel
• Who prepares the notification
• Who submits the notification
• Who maintains the submission record
• Who coordinates communications with other parties

This is a governance issue as much as a technical one.

6. Determine Whether Clients or Other Parties Must Be Notified

FTC notification is only one potential communication requirement.

Depending on the incident, the firm may also have obligations arising from:

• State data breach laws
• Contracts
• Professional obligations
• Cyber insurance requirements
• Client agreements
• Third-party provider agreements
• Other applicable federal requirements

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.

Client communication should be factual

When communicating with an affected client, the firm should be prepared to explain:

• What happened
• When it occurred
• What information was involved
• What the firm has done to contain the incident
• What investigation remains underway
• What actions the client should take, if any
• How the firm will provide additional updates

The objective is to communicate verified information without speculating about facts that have not yet been established.

7. Remediate the Underlying Security Weakness

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:

• Reset credentials
• Revoke sessions
• Review MFA configuration
• Review authentication policies
• Investigate mailbox activity
• Review connected applications
• Review privileged access
• Check for similar account exposures

Ransomware incident

Potential remediation:

• Isolate affected systems
• Identify the initial access path
• Remove malicious persistence
• Patch exploited vulnerabilities
• Review privileged access
• Validate endpoint protection
• Test backup integrity
• Validate recovery procedures
• Review segmentation and administrative controls

Unauthorized access to cloud files

Potential remediation:

• Review permissions
• Remove unnecessary access
• Investigate sharing settings
• Review third-party applications
• Validate identity controls
• Improve monitoring
• Review data classification and retention

The goal is to address the control failure, not simply restore the affected system.

8. Validate Backup and Recovery

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:

• What backups remain available?
• Are backups isolated from the affected environment?
• Are backups known to be clean?
• How quickly can critical systems be restored?
• Which systems need to be restored first?
• Has restoration been tested?
• What data could be lost between the last backup and the incident?

For accounting firms, recovery priorities should be tied to business operations.

Critical systems may include:

• Microsoft 365
• Tax applications
• Accounting systems
• Document management
• Client portals
• File repositories
• Identity infrastructure
• Line-of-business applications

Recovery objectives should be documented before an incident occurs, not determined for the first time while systems are unavailable.

9. Document the Incident

Documentation is part of effective incident response.

The incident record should capture:

• What happened
• When it happened
• How it was detected
• Systems and accounts affected
• Customer information involved
• Investigation findings
• Containment actions
• Notifications considered or completed
• Remediation actions
• Recovery activities
• Decisions made
• Individuals involved
• Lessons learned

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.

10. Conduct a Post-Incident Review

The final stage is turning the incident into measurable improvement.

A post-incident review should ask:

What control failed?

Was the issue related to identity, endpoint security, email, configuration, monitoring, backup, employee behavior, vendor access, or another control?

Why did the control fail?

Was it missing, incorrectly configured, bypassed, poorly monitored, or not consistently maintained?

Could the incident have been detected earlier?

Review the available security telemetry and determine whether the organization had the necessary visibility.

Could the impact have been reduced?

Consider whether stronger access controls, better segmentation, improved backup isolation, or faster response could have reduced the scope.

What changes are required?

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.

What Should an Accounting Firm's Incident Response Plan Include?

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:

• Incident severity levels
• Roles and responsibilities
• Escalation procedures
• Internal communication
• Technical containment procedures
• Investigation procedures
• Evidence preservation
• Customer information assessment
• Legal and regulatory review
• FTC notification procedures
• Client communication
• Backup and recovery procedures
• Cyber insurance notification
• Third-party coordination
• Post-incident review
• Documentation requirements

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.

How Microsoft 365 Fits Into GLBA Incident Response

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:

• MFA coverage
• Suspicious sign-ins
• Privileged accounts
• Conditional access policies
• Administrative activity
• Email forwarding rules
• SharePoint and OneDrive access
• External sharing
• Third-party application permissions
• Endpoint activity
• Audit logs
• Security alerts

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.

What Should an IT Provider Do During a GLBA Security Incident?

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:

• Who monitors security alerts?
• Who receives the first notification?
• Who has authority to isolate systems?
• Who investigates suspicious activity?
• Who preserves relevant evidence?
• Who determines what customer information may be affected?
• Who coordinates with legal counsel?
• Who evaluates regulatory notification requirements?
• Who manages recovery?
• Who documents the incident?
• Who reports remediation progress to leadership?

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.

How to Measure Incident Response Performance

Incident response should be measured like any other operational process.

Useful metrics include:

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.

The Goal Is a Repeatable Incident Response Process

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:

• Maintain an accurate inventory of customer information
• Maintain a written risk assessment
• Know which systems contain customer information
• Implement appropriate identity and access controls
• Monitor meaningful security activity
• Maintain tested backups
• Document the incident response plan
• Establish legal and regulatory escalation procedures
• Define responsibilities with IT and security providers
• Regularly test the response process

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.

FAQ

Does GLBA require accounting firms to have an incident response plan?

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.

What happens after a GLBA security incident?

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.

When does a GLBA security incident have to be reported to the FTC?

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.

Does every accounting firm security incident require 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.

What information does an accounting firm need to investigate after a security incident?

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.

What should an accounting firm's GLBA incident response plan include?

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.

Does Microsoft 365 help with GLBA incident response?

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.

What should an accounting firm's IT provider do during a security incident?

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.

How should an accounting firm test its incident response plan?

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.

How long does a GLBA breach investigation take?

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.

Does GLBA require accounting firms to notify affected clients?

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.

What is the most important thing an accounting firm can do before a GLBA security incident?

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.