IRS WISP Readiness

IRS WISP Requirements Explained for Tax and Accounting Practices

Define the operating boundary for IRS WISP requirements explained for tax by following the real data, systems, services, contracts, people, and third parties that create responsibility.

CISO-led guidance from Ali Hassani, backed by 25+ years of IT, cybersecurity, compliance, and infrastructure experience.

Written information security plan and technical safeguards review
A useful WISP connects written requirements to owners, configurations, testing, evidence, and management decisions.

A WISP Is an Operating System for Information Security

The written plan connects management decisions to the actual environment. It identifies who is accountable, which information and systems are covered, how risks are evaluated, which safeguards are approved, how incidents are handled, and how the firm proves that controls continue to operate.

A policy without operational evidence is incomplete. A collection of security products without documented scope, ownership, risk decisions, and validation is also incomplete.

From Requirement to Operating Control

Program function Operational question Evidence expected
Governance Who has authority to maintain the program and report material risk? Designation, approvals, review records, management reporting
Risk assessment Which threats and vulnerabilities affect customer information? Inventory, methodology, risk register, treatment decisions
Access control Who can access each system and how is that access approved? User lists, MFA coverage, role definitions, periodic reviews
Data protection How is information protected in storage, transit, use, backup, and disposal? Encryption settings, data flows, backup tests, disposal records
Detection and response How will the firm identify, contain, investigate, and communicate an incident? Logs, alerts, response plan, contacts, exercises, case records
Provider oversight How are providers selected, monitored, and offboarded? Register, due diligence, contracts, findings, reassessments

Administrative, Technical, and Physical Safeguards Work Together

Administrative safeguards create accountability through policy, risk management, training, access governance, vendor oversight, and incident procedures. Technical safeguards protect identities, devices, applications, networks, email, cloud tenants, logs, and backups. Physical safeguards address offices, paper, devices, visitors, equipment disposal, and environmental exposure.

A gap in one area can defeat controls in another. MFA does not protect an exported taxpayer file stored on an unmanaged laptop; encryption does not correct excessive access; a strong firewall does not compensate for untested recovery.

Proportionality Must Be Supported by Risk Analysis

A smaller practice may use simpler processes, but the decision should be documented. Record why a safeguard is appropriate, what alternatives were considered, who approved an exception, what compensating controls exist, and when the decision will be revisited.

Reassess after material changes to services, software, staffing, locations, vendors, threat conditions, or applicable requirements.

The Safeguards Rule Program Elements in Operational Terms

Qualified Individual and governance

Designate a person with sufficient knowledge and authority to implement and supervise the program. Define escalation thresholds, exception authority, budget coordination, and reporting. If the role is outsourced, assign a senior employee to supervise the provider.

Written risk assessment

Document criteria for evaluating threats, likelihood, impact, existing safeguards, and residual risk. Cover information systems, personnel, locations, providers, and foreseeable misuse or loss. Reassess periodically and after material change.

Safeguard design and implementation

Address access control, inventory, encryption, MFA, secure disposal, change management, logging, monitoring, and controls selected through risk analysis. Document effective alternatives and Qualified Individual approval when encryption is not feasible.

Testing and continuous improvement

Validate that safeguards operate through monitoring, vulnerability assessment, penetration testing where applicable, exercises, sampling, and corrective-action tracking. Closure should require evidence, not only an implementation statement.

Training and security personnel

Provide awareness training for the workforce and specialized training for people who operate the program. Confirm that internal or external security personnel maintain current knowledge of changing threats and countermeasures.

Service-provider oversight

Select providers capable of safeguarding customer information, require appropriate safeguards by contract, and periodically assess continued adequacy based on the service and risk.

Incident response and reporting

Maintain a written response plan with roles, communications, remediation, documentation, and post-incident improvement. Predefine who evaluates FTC reporting and other notification duties with qualified counsel.

Annual management reporting

The Qualified Individual should report in writing at least annually to the board, governing body, or responsible senior officer. Cover program status, risk decisions, providers, tests, events, management response, and recommended changes.

See the FTC’s current Safeguards Rule guidance for authoritative details and applicability considerations.

Design, Implementation, and Operating Effectiveness Are Different

Designed

The control has an objective, scope, owner, procedure, and expected evidence.

Implemented

The configuration or process exists across the intended systems, people, and locations.

Operating

Reviews, alerts, approvals, tests, and corrective actions show the control functions over time.

Improved

Risk changes, incidents, testing, and business changes lead to measured updates.

An MFA policy is only design. Enrollment records show implementation. Coverage reports, exception review, and authentication monitoring demonstrate operation.

Security Event Reporting Requires a Decision Process

The Safeguards Rule includes notification requirements for certain events involving at least 500 consumers. The firm should not wait for an incident to determine who evaluates the threshold, what facts must be collected, who coordinates legal analysis, and how reporting is approved. The FTC security event reporting resource describes the submission process.

The WISP should distinguish operational escalation from legal notification. Staff need a simple method to report suspicious events immediately; qualified legal and compliance personnel determine applicable notices based on verified facts.

Translating WISP Requirements Into Technical and Operational Controls

Ali Hassani, CISO, has more than 25 years of experience connecting compliance requirements to identity, endpoint, network, Microsoft 365, cloud, backup, monitoring, provider, and incident-response controls. He can help a tax or accounting practice distinguish policy language from controls that are actually configured, tested, and supported by evidence.

Ali can work alongside leadership, internal IT personnel, or an existing MSP to define ownership, identify implementation dependencies, review exceptions, and create validation criteria. This is especially useful when a firm has security products in place but cannot demonstrate whether the full Safeguards Rule program operates consistently.

Authoritative Guidance

Use current official guidance when determining applicability and designing safeguards. This educational page does not replace legal, regulatory, tax, or professional compliance advice.