For accounting firms subject to the Gramm-Leach-Bliley Act (GLBA), cybersecurity is not simply an IT responsibility. The GLBA Safeguards Rule requires covered financial institutions under the Federal Trade Commission's jurisdiction to maintain a written information security program designed to protect customer information.
That makes the relationship with your IT provider an important part of your GLBA cybersecurity strategy.
Your provider may manage Microsoft 365, endpoints, identity security, backups, security monitoring, or other systems containing customer information. But outsourcing technology does not outsource the firm's responsibility for its information security program. The FTC specifically states that a company using a service provider to implement or supervise its security program remains responsible for overseeing that relationship.
So instead of asking only, "Are we GLBA compliant?", accounting firm leadership should ask a more practical question:
Can our IT provider demonstrate that the technology environment, security controls, and processes supporting our firm address the risks identified in our GLBA information security program?
The following seven questions can help.
A strong IT provider should be able to answer these questions clearly, provide evidence where appropriate, and explain how identified gaps are being addressed.
The goal is not to test your provider with technical terminology. It is to determine whether the provider can connect its day-to-day IT and cybersecurity activities to the firm's broader information security obligations.
The Safeguards Rule requires a covered firm's information security program to be based on a written risk assessment.
The assessment should identify reasonably foreseeable internal and external risks to customer information, evaluate existing safeguards, and be periodically reassessed as the firm's operations and risks change.
Your IT provider may contribute significantly to that assessment, but leadership should understand what it actually contains.
A useful risk assessment should go beyond a generic cybersecurity score.
For an accounting firm, it should consider the actual environment, including:
You should be able to see a clear connection between:
Risk → Control → Evidence → Remediation
For example, if compromised credentials are identified as a significant risk, the provider should be able to explain which identity controls mitigate that risk, how those controls are monitored, where exceptions exist, and what is being done to address them.
A risk assessment that produces no measurable remediation is difficult to use as an ongoing management tool.
Multifactor authentication is a core Safeguards Rule requirement for individuals accessing customer information on information systems, unless an equivalent form of secure access control is approved in writing by the Qualified Individual.
For accounting firms, the question should not be limited to whether MFA is enabled for Microsoft 365 email.
Ask where users, administrators, vendors, and applications can access systems containing customer information.
That may include:
Instead of hearing:
"MFA is enabled."
You should be able to hear:
"MFA is enforced for all applicable accounts. We have two documented exceptions, both with defined remediation dates."
That is a much more useful security metric because it measures coverage and identifies residual risk.
The Safeguards Rule requires covered organizations to understand what customer information they have and where it is stored, collected, or transmitted. It also requires encryption of customer information on systems and while in transit, unless encryption is not feasible and effective alternative controls are approved by the Qualified Individual.
Your IT provider should therefore be able to explain how customer information moves through your technology environment.
For Microsoft 365 environments, the conversation should extend beyond email.
Consider:
Your provider should be able to map the firm's major customer information repositories and explain the controls protecting each one.
You should also be able to identify exceptions.
If a particular system cannot support a required security control, that should be a documented risk decision rather than an unknown gap.
Not every user account presents the same level of risk.
Administrative accounts can change configurations, create or disable users, access sensitive systems, modify security controls, and potentially access large amounts of customer information.
That makes privileged access an important part of any accounting firm's identity security strategy.
That last question is particularly important.
If an IT provider has administrative access to the firm's Microsoft 365 tenant, endpoints, network, backup systems, or other platforms containing customer information, that access should be incorporated into the firm's risk assessment and service-provider oversight process.
The firm can identify:
A low number of administrators is not the objective by itself. The objective is controlled, justified, monitored privileged access.
Security tools only reduce risk when someone can identify and respond to meaningful events.
The Safeguards Rule requires covered organizations to regularly monitor and test the effectiveness of safeguards. Depending on the firm's approach, this can involve continuous monitoring or the testing and vulnerability assessment requirements specified by the rule.
Your IT provider should be able to explain what happens after a security alert occurs.
A provider should be able to show more than a dashboard full of alerts.
Ask for operational measures such as:
The objective is to understand whether monitoring is producing meaningful action.
Every accounting firm should know what happens when something goes wrong before an incident occurs.
The Safeguards Rule requires a written incident response plan that addresses how the firm will respond to and recover from security incidents affecting the confidentiality, integrity, or availability of customer information. The plan should establish roles, responsibilities, decision-making authority, communications, remediation, documentation, and reporting procedures.
Your IT provider may be responsible for significant portions of the technical response, but the firm's leadership still needs to understand the overall process.
The GLBA Safeguards Rule also contains a specific FTC notification requirement for certain security events involving at least 500 consumers' information. Covered financial institutions must notify the FTC as soon as possible and no later than 30 days after discovery of a qualifying notification event involving unauthorized acquisition of unencrypted customer information.
The specific facts of an incident determine whether that requirement applies, and other federal, state, contractual, or professional obligations may also be relevant.
Your firm should know:
Who → Does What → When → With What Authority → Using What Process
An incident response plan that exists only as a document is less useful than one that has been exercised and updated based on what the firm learned.
Your IT provider is not necessarily the only third party with access to customer information.
An accounting firm's technology ecosystem may include:
The Safeguards Rule requires covered financial institutions to take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards, establish appropriate security requirements through contracts, monitor provider performance, and periodically reassess their suitability.
This is particularly important when an IT provider recommends or manages third-party technology on the firm's behalf.
Your firm should maintain a current inventory of important service providers and understand:
Not every vendor requires the same level of scrutiny. Risk-based oversight should focus more attention on providers with access to sensitive customer information or critical systems.
The seven questions above are useful because they shift the conversation from claims to evidence.
When evaluating your IT provider, ask for documentation or reporting that demonstrates how the program operates.
Examples include:
| Area | Evidence to request |
|---|---|
| Risk management | Current written risk assessment and remediation plan |
| Identity | MFA coverage and privileged-account review |
| Data protection | Data inventory, encryption coverage, access reviews |
| Endpoint security | Device coverage, security status, vulnerability reporting |
| Monitoring | Security event and response reporting |
| Incident response | Current plan and most recent exercise or review |
| Employee security | Training completion and relevant behavior metrics |
| Vendor oversight | Critical vendor inventory and review status |
| Testing | Vulnerability assessments, penetration testing, or monitoring evidence |
| Governance | Security reporting provided to leadership |
The specific documentation will vary based on the firm's environment and the provider's responsibilities.
The underlying principle is simple:
If a security control matters, the firm should be able to determine whether it exists, whether it is working, and whether exceptions are being managed.
Cybersecurity reporting becomes more useful when it focuses on outcomes rather than the number of tools deployed.
Instead of reporting:
"We have endpoint protection."
Consider measuring:
Percentage of active endpoints protected and managed.
Instead of:
"We conduct security awareness training."
Measure:
Training completion, phishing reporting behavior, and repeat failures.
Instead of:
"We monitor security events."
Measure:
Coverage of critical systems, high-severity events investigated, and response times.
Instead of:
"We have a risk assessment."
Measure:
Number of high-risk findings, remediation status, and time to address identified gaps.
A practical cybersecurity scorecard for leadership might include:
These measures help leadership understand whether security controls are producing measurable improvements.
The purpose of these questions is not to create an adversarial relationship with an IT provider.
It is to establish whether the provider's services align with the firm's risk-management responsibilities.
If your provider cannot answer a question, start by determining why.
The issue may be:
Each situation calls for a different response.
The important thing is to make the gap visible and assign an owner.
A useful discussion with an IT provider should ultimately produce:
Gap → Risk → Owner → Action → Deadline → Evidence
That creates accountability without turning cybersecurity into a checklist exercise.
For accounting firms operating primarily in Microsoft 365, identity and cloud security should be a central part of the discussion with the IT provider.
Ask how the provider manages:
Microsoft 365 provides security capabilities that can support an accounting firm's GLBA information security program, but the platform itself does not establish compliance.
The firm's security program still needs to identify risks, implement appropriate controls, monitor those controls, test their effectiveness, manage service providers, respond to incidents, and maintain appropriate governance.
For accounting firm leadership, the most important shift is moving from asking whether the IT provider is "taking care of security" to establishing who is responsible for each part of the security program.
A practical operating model looks like:
Firm leadership → Risk ownership and governance
Qualified Individual → Information security program oversight
IT/security provider → Technical implementation and operations
Employees → Secure behaviors and incident reporting
Technology vendors → Protection of data within their services
That model creates clearer accountability.
The IT provider can operate the technology. Leadership can make risk decisions. Employees can follow security requirements. Vendors can be held to defined security expectations.
Together, those responsibilities form a functioning information security program.
No IT provider can reduce cybersecurity to a simple yes-or-no answer.
For an accounting firm subject to GLBA, the more useful conversation is whether the firm's security program is appropriately designed, consistently implemented, monitored, tested, and improved.
That means asking:
The answers should become part of an ongoing operating rhythm between firm leadership and the IT provider.
GLBA establishes the obligation to protect customer information. Your IT provider should help turn that obligation into a security program that can be measured, managed, and improved.
GLBA can apply to accounting firms because the FTC identifies tax preparation firms, accountants, and other financial advisers among businesses that may qualify as financial institutions depending on their activities. Whether a specific firm is covered depends on its activities and applicable regulatory jurisdiction.
Accounting firms should ask their IT provider about the firm's risk assessment, MFA coverage, data protection, privileged access, security monitoring, incident response, and service-provider oversight. These questions help determine whether the technology environment supports the firm's GLBA information security program.
No. An IT provider can implement and operate security controls, but the accounting firm remains responsible for its information security program. The FTC specifically states that using a service provider does not eliminate the firm's responsibility for overseeing its security program.
A GLBA risk assessment should identify reasonably foreseeable internal and external risks to customer information, evaluate existing safeguards, and establish how identified risks will be addressed. It should be written and periodically reassessed as the firm's operations and risk environment change.
The Safeguards Rule requires multifactor authentication for individuals accessing customer information on an information system, unless an equivalent form of secure access control is approved in writing by the Qualified Individual.
An IT provider should monitor security events relevant to the firm's customer information and information systems. Depending on the environment, that can include suspicious Microsoft 365 sign-ins, privileged account activity, endpoint threats, authentication anomalies, unusual data access, and other security events.
Evaluate whether the provider can demonstrate effective risk management, identity security, data protection, monitoring, incident response, vulnerability management, security testing, and service-provider oversight. Ask for measurable evidence and documentation rather than relying only on descriptions of the provider's services.
Yes. The Safeguards Rule requires covered organizations to encrypt customer information on their systems and in transit, unless encryption is not feasible and effective alternative controls are approved in writing by the Qualified Individual.
Yes. Covered financial institutions under the Safeguards Rule must maintain a written incident response plan addressing how the firm will respond to and recover from security incidents affecting customer information.
No. The FTC notification requirement applies to specific qualifying notification events. Covered financial institutions must notify the FTC as soon as possible and no later than 30 days after discovery of a notification event involving unauthorized acquisition of unencrypted customer information affecting at least 500 consumers.
Microsoft 365 can provide capabilities relevant to GLBA security controls, including MFA, identity and access management, endpoint security, email protection, encryption, logging, and security monitoring. However, using Microsoft 365 does not by itself establish GLBA compliance. The firm still needs a risk-based information security program and appropriate governance, processes, controls, testing, and oversight.
Ask the provider to demonstrate how its services address the risks identified in the firm's written risk assessment. The strongest conversation connects each significant risk to a specific control, an owner, measurable evidence that the control is working, and a documented plan for addressing exceptions or gaps.