Written Information Security Program (WISP)

This Written Information Security Program ("WISP") describes the administrative, technical, and physical safeguards SendTax maintains to protect customer information and is the program referenced in our Privacy Policy.

This document is designed to satisfy the requirements of:

• The FTC Standards for Safeguarding Customer Information ("Safeguards Rule"), 16 CFR Part 314 (as amended).
• IRS Publication 4557 ("Safeguarding Taxpayer Data") and the related Publication 5708 WISP guidance.
• IRS Publication 1345 ("Handbook for Authorized IRS e-file Providers") to the extent it applies to tax-document workflows.
• The New York SHIELD Act "reasonable safeguards" standard (N.Y. Gen. Bus. Law § 899-bb).

This is an internal compliance document. It may be shared with auditors, regulators, enterprise customers under NDA, and the IRS on request. A summary suitable for public Trust Center publication is maintained separately in our Information Security document.

Items marked Roadmap are not yet in production. The WISP names them explicitly rather than allowing them to read as current controls.

---

1. Scope and applicability

This WISP covers:

• Customer information as defined by the Safeguards Rule: any record containing nonpublic personal information about a consumer of SendTax services, in any form. This includes taxpayer identity information, financial account information, tax-return data, and supporting documents.
• Customer information systems: every SendTax-operated system that processes, stores, or transmits customer information, including application code, databases, document storage, and the operator endpoints used to administer them.
• Personnel: SendTax operators, employees, and contractors of Howell & Gibbs LLC with any access to customer information or customer information systems.
• Service providers: every Tier 1 sub-processor listed on our Sub-processors page.

It does not cover information that is not "customer information" under the Safeguards Rule (e.g., public-website telemetry stripped of identifiers, internal corporate records of Howell & Gibbs LLC unrelated to customer information).

---

2. Designation of a Qualified Individual

The Safeguards Rule (16 CFR § 314.4(a)) requires designation of a Qualified Individual responsible for overseeing, implementing, and enforcing this program.

Liam Howell, Co-founder, SendTax, is designated as the Qualified Individual responsible for overseeing, implementing, and enforcing this information security program.

The Qualified Individual:

• Has overall responsibility for the design, implementation, and ongoing operation of this WISP.
• Has authority to make decisions about safeguards, including decisions to suspend services or accept risk during incidents.
• Provides a written report to the governing body of Howell & Gibbs LLC at least annually, summarizing the status of this program, material risks, the results of testing, and any recommended changes (see § 11).
• Delegates day-to-day execution as appropriate but remains accountable.

For absences exceeding two business days, the Qualified Individual designates a delegate in writing.

---

3. Risk assessment

The Safeguards Rule (16 CFR § 314.4(b)) requires a written risk assessment.

3.1 Scope of the assessment

The risk assessment evaluates reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information that could result in unauthorized disclosure, misuse, alteration, destruction, or other compromise.

3.2 Method

For each identified risk, the assessment records:

• The nature of the risk (threat).
• The systems or data affected (assets).
• The likelihood and impact, qualitatively rated (low / moderate / high / critical).
• The current safeguards that address the risk.
• Any residual risk and the planned remediation.

3.3 Cadence

The risk assessment is reviewed and updated:

• At least annually.
• Whenever a material change occurs in operations, systems, or the threat landscape.
• Following any Critical-severity incident.

3.4 Current status

A structured, written risk assessment in the form described above is on our roadmap. (Roadmap.) As of v1 of this WISP:

• The risks addressed by safeguards in § 4 reflect threats that have been considered and addressed informally during product design.
• A first formal documented risk assessment will be completed before the first annual report to the governing body (§ 11).
• This WISP will be updated to reference the dated risk assessment when complete.

---

4. Safeguards

The Safeguards Rule (16 CFR § 314.4(c)) requires specific administrative, technical, and physical safeguards. The following subsections map each required element to the controls SendTax has implemented.

4.1 Access controls (314.4(c)(1))

Requirement: Implement and periodically review access controls to authenticate and permit access only to authorized users.

SendTax controls: Implemented in full. Three-layer authorization (identity provider → application layer → PostgreSQL Row-Level Security with FORCE ROW LEVEL SECURITY), documented in the Access Control Policy. Periodic access review is annual, with quarterly cadence on the roadmap.

4.2 Inventory of data, systems, and personnel (314.4(c)(2))

Requirement: Identify and manage the data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes.

SendTax controls:

• Data inventory. Categories and retention windows are documented in the Data Retention and Deletion Policy.
• Systems inventory. The application architecture is documented in the monorepo CLAUDE.md and reflected in source-controlled fly.toml configurations.
• Sub-processor inventory. Maintained on the Sub-processors page and as an internal vendor inventory per the Vendor Management Policy.
• Personnel inventory. Maintained internally; the Qualified Individual keeps the list current with the small operator population.
• Device inventory. Each operator's primary device is recorded in the personnel inventory along with full-disk encryption status. (Roadmap: a structured device-inventory record for each named operator.)

4.3 Encryption (314.4(c)(3))

Requirement: Protect by encryption all customer information held or transmitted by the organization both in transit over external networks and at rest.

SendTax controls: Implemented in full and documented in the Encryption Policy:

• In transit: TLS 1.2 or higher on all customer-facing and service-to-service traffic; no prohibited algorithms.
• At rest: AES-256-GCM envelope encryption with per-document DEKs, KEK custody in Google Cloud KMS, AAD binding to document and filer identifiers. Database and object-storage layers provide additional encryption at rest.

A codebase audit on 2026-05-21 confirmed no usage of any prohibited algorithm (MD5, SHA-1, DES, 3DES, RC4, TLS 1.0/1.1, SSL).

4.4 Secure development (314.4(c)(4))

Requirement: Adopt secure development practices for in-house developed applications and procedures for evaluating, assessing, or testing the security of externally developed applications.

SendTax controls: Implemented in full and documented in the Change Management Policy:

• Pre-commit hooks for format, type, and quality checks are defined in the repository; the hook installed day to day is advisory and does not block a commit (Change Management Policy § 5.3).
• Continuous integration runs lint, type-check, unit tests, and schema-drift checks on every pull request. Integration tests and dependency audits run in a daily full run that gates the staging deploy. Our source-control plan does not support branch protection, so a failing check does not technically block a merge; merging only on green is an operator practice, not a technical control.
• Sensitive-area changes (encryption, RLS, authentication, audit log) are listed in the Change Management Policy § 6.3. SendTax has one engineer, so the author is also the area owner and these changes get no second human review. (Roadmap: a second reviewer.)
• Production deploys flow through a single, audited release workflow that gates production behind a staging run of the same artifact.
• External dependencies are scanned automatically for known vulnerabilities.

4.5 Multi-factor authentication (314.4(c)(5))

Requirement: Implement multi-factor authentication for any individual accessing any information system, unless the Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls.

SendTax controls:

• For operators (internal access). MFA is required for the identity provider (Clerk), the hosting provider (Fly.io), the source-control provider (GitHub), the key-management provider (Google Cloud), the storage provider (Cloudflare), the secret-management provider (1Password), and every other Tier 1 vendor that supports it. This is implemented in full.
• For customers (filers and tax-professional users). MFA for tax-professional firm users (firm role firm administrator or firm member) and for SendTax administrators is not available yet. (Roadmap.) No second factor is enabled in our identity provider (Clerk), so customers cannot enroll, and sign-in enforcement is off. When MFA becomes available, authenticator-app MFA with backup codes comes first and enforcement follows. The enforcement code is built: once switched on, it runs at sign-in (the /oidc-login token exchange, evaluated once per sign-in rather than on every authenticated request), with a grace window in which a not-yet-enrolled user is warned and allowed through before sign-in is blocked. Until then, customer sign-in relies on Clerk's password requirements, breach-password detection, and rate limiting. For filers, MFA will be optional. The per-client Preparer/Viewer designations are access levels on a filer link, distinct from the firm role that drives MFA.

4.6 Disposal of customer information (314.4(c)(6))

Requirement: Develop, implement, and maintain procedures for the secure disposal of customer information no later than two years after the last date the information is used.

SendTax controls: Documented in the Data Retention and Deletion Policy. The default retention is 7 years after the last activity on an account (ACCOUNT_RETENTION_DAYS / DOCUMENT_RETENTION_DAYS = 2,557 days), the same period our public Privacy Policy states. The Rule allows retention past two years where the information is necessary for a legitimate business purpose. Business need: a firm needs the documents behind a return for as long as the IRS can still examine it or a taxpayer can still claim a refund, which is up to 7 years (IRS Publication 583, "How long to keep records"). Customers can have their information deleted sooner on request. The automated hard-deletion sweeps for soft-deleted accounts, expired documents, and identity records are implemented and run daily on the worker schedule; they currently operate in dry-run mode (logging would-purge candidates with a queryable audit row each) pending production enablement of their retention flags. Until they are enabled, nothing is deleted automatically: deletion happens on request, by hand. Cryptographic erasure via DEK destruction is available as a mechanism, per the Encryption Policy.

4.7 Change management (314.4(c)(7))

Requirement: Adopt procedures for change management.

SendTax controls: Documented in the Change Management Policy. Every change goes through a pull request, CI, and a staging-then-production release flow. SendTax has one engineer, so most changes are merged by their author without a second human reviewer (Change Management Policy § 6.2). The single sanctioned production-deploy path is enforced at the workflow level in release.yml.

4.8 Monitoring and logging (314.4(c)(8))

Requirement: Implement policies, procedures, and controls designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information.

SendTax controls: Implemented:

• Application audit log. A hardened audit_log table records authentication events, role changes, administrative actions, sensitive-data access, and tenant-filer relationship changes. Documented in Access Control Policy § 8.
• Application telemetry. Sentry captures errors and anomalies; payloads are scrubbed of known sensitive fields before transmission.
• Authentication telemetry. Clerk records sign-in events, failed attempts, and suspicious patterns.
• Infrastructure telemetry. Fly.io platform metrics, health checks, and deploy history.
• Audit-log retention. At least three years, matching the longest tax-data retention obligation.

---

5. Regular testing or monitoring (314.4(d))

Requirement: Regularly test or otherwise monitor the effectiveness of safeguards' key controls, systems, and procedures, including those to detect actual and attempted attacks on, or intrusions into, information systems. Where continuous monitoring is not used, annual penetration testing and biannual vulnerability assessments are required.

SendTax current posture:

• Continuous monitoring of application errors and authentication anomalies via Sentry and Clerk.
• Continuous testing of code-level safeguards via CI (lint, type, unit, integration, and selected E2E suites).
• Automated dependency scanning for known vulnerabilities in the daily full CI run (not on every pull request).
• Continuous health monitoring of production services via Fly.io health checks.

Currently missing — Roadmap:

• Annual third-party penetration test. (Roadmap.)
• Biannual vulnerability assessment by a qualified external party. (Roadmap.)
• External Approved Scanning Vendor (ASV) scans on a weekly cadence as referenced in our Privacy Policy's IRS Pub 1345 alignment statement. (Roadmap. The Privacy Policy lists it as roadmap too.)
• Tabletop exercise for representative incident scenarios. (Roadmap, also tracked in the Incident Response Policy.)

Until external pen-testing and ASV scanning are in place, the program meets the "continuous monitoring" branch of 314.4(d) but does not satisfy the alternative annual-pentest / biannual-vulnerability-assessment branch. The Qualified Individual has documented this gap.

---

6. Personnel security and training (314.4(e))

Requirement: Implement policies and procedures to ensure that personnel are able to enact the program. Provide security awareness training. Use qualified information-security personnel. Verify that key personnel maintain current knowledge of changing information-security threats.

SendTax controls:

• Hiring. All personnel with access to customer information are employees or named contractors of Howell & Gibbs LLC and acknowledge the obligations of this WISP at onboarding.
• Onboarding. Each new operator receives an orientation to this WISP and the companion Trust Center documents before being granted production access.
• Training. The Qualified Individual maintains current knowledge through industry publications, FTC and IRS guidance updates, and security-vendor advisories.
• Acceptable use. All operators are bound by the Employee Acceptable Use Policy, which applies stricter production-system handling rules than the customer-facing User Acceptable Use Policy.
• Annual security-awareness training with documented completion records for all personnel is on our roadmap and will be in place before the first annual report to the governing body. (Roadmap.)

---

7. Service provider oversight (314.4(f))

Requirement: Oversee service providers by (1) taking reasonable steps to select and retain providers capable of maintaining appropriate safeguards; (2) requiring providers by contract to implement and maintain such safeguards; and (3) periodically assessing such providers based on the risk they present and the continued adequacy of their safeguards.

SendTax controls: Implemented in full and documented in the Vendor Management Policy. Every Tier 1 sub-processor has a Data Processing Agreement, is evaluated against documented selection criteria, and is reviewed at least annually. The current list of Tier 1 sub-processors is published at Sub-processors.

---

8. Evaluation and adjustment (314.4(g))

Requirement: Evaluate and adjust the information security program in light of the results of testing and monitoring; any material changes to operations or business arrangements; the results of risk assessments; or any other circumstances that may have a material impact on the program.

SendTax controls: This WISP and each companion policy carries an explicit review cadence and a list of triggers (material change, incident, regulatory change) for out-of-cycle review. The Qualified Individual is responsible for ensuring the program is updated when any trigger fires.

A combined annual review of every Trust Center document and the underlying internal evidence is conducted before each annual report to the governing body.

---

9. Incident response (314.4(h))

Requirement: Establish a written incident response plan designed to respond to and recover from any security event materially affecting the confidentiality, integrity, or availability of customer information in the organization's control.

SendTax controls: Implemented in full and documented in the Incident Response Policy. The plan addresses each required element:

• Goals. Defined in IR Policy § 1.
• Internal processes for responding. IR Policy §§ 4–7.
• Roles, responsibilities, levels of decision-making authority. IR Policy § 5.
• External and internal communications and information sharing. IR Policy §§ 8–9, including statutory notification obligations (GDPR Art. 33–34, U.S. state breach notification statutes, IRS tax-data obligations).
• Identification of requirements for remediation. IR Policy §§ 7.3–7.4.
• Documentation and reporting regarding security events and related incident response activities. IR Policy §§ 10 and 11, backed by a real database-level incident-management system.
• Evaluation and revision of the incident response plan following a security event. IR Policy §§ 11 and 15.

SendTax additionally commits to next-business-day incident reporting to the IRS for events affecting tax-data systems, consistent with our Privacy Policy's IRS Pub 1345 alignment statement.

---

10. Notification of FTC and customers

Requirement (314.4(j), as amended 2023): Notify the FTC electronically as soon as possible, and no later than 30 days after discovery, of any notification event involving the information of 500 or more consumers.

SendTax control: Acknowledged and committed to in our Privacy Policy. Operational responsibility sits with the Communications Lead during incident response, who works with the Qualified Individual to confirm the threshold has been met and to file the required notification via the FTC's electronic reporting portal. The documented incident-management system retains a durable record of any such notification.

State breach notification statutes are tracked separately; notification is made on the most stringent applicable timeline, as described in Incident Response Policy § 9.

---

11. Annual report to the governing body (314.4(i))

Requirement: The Qualified Individual reports in writing, regularly and at least annually, to the board of directors or equivalent governing body on:

• The overall status of the information security program and compliance with the Safeguards Rule.
• Material matters related to the information security program, addressing issues such as risk assessment; risk management and control decisions; service provider arrangements; results of testing; security events or violations and management's responses; and recommendations for changes in the program.

SendTax control: The Qualified Individual produces a written Annual WISP Report addressed to the members of Howell & Gibbs LLC. The first report will be issued before 2027-05-21 (within twelve months of this WISP's effective date) and annually thereafter.

Each report covers, at minimum:

• The status of each safeguard in § 4.
• The results of testing and monitoring during the period (§ 5), including any pen-test or vulnerability-assessment results once those programs are in place.
• The status of each item on the WISP roadmap, including any items that have shipped during the period and any new items added.
• Material changes to operations, systems, or sub-processors.
• A summary of any Critical or High-severity incidents during the period, with links to the incident records and any postmortems.
• Recommendations for changes to this WISP.

The completed annual report and the governing body's acknowledgment are retained in the WISP's evidence archive.

---

12. Tax-data-specific overlay (IRS guidance)

In addition to the Safeguards Rule, SendTax aligns with tax-preparer-specific guidance from the IRS.

12.1 IRS Publications 4557 and 5708

This WISP is structured to satisfy the WISP-template guidance in IRS Publications 4557 and 5708 ("Creating a Written Information Security Plan for Your Tax & Accounting Practice"). The mapping of Pub 5708 sections to this WISP is maintained internally for audit and is available on request.

12.2 IRS Publication 1345 (e-file ecosystem)

For tax-document workflows that interact with the IRS e-file ecosystem, SendTax aligns with the security expectations of IRS Pub. 1345. The current status of each expectation is:

12.3 PTIN and Circular 230

Tax professionals using SendTax are required to hold a valid PTIN and comply with Treasury Circular 230. The PTIN obligation is enforced at the data-model level (the preparers.ptin column is non-nullable and unique). Circular 230 compliance is the responsibility of the individual preparer; SendTax facilitates but does not validate it.

---

13. New York SHIELD Act alignment

The New York SHIELD Act (N.Y. Gen. Bus. Law § 899-bb) requires "reasonable safeguards" administrative, technical, and physical. The safeguards described in § 4 of this WISP, together with the operational practices in §§ 5–9, are designed to satisfy the SHIELD Act's "reasonable safeguards" standard for any New York resident whose private information is processed by SendTax.

---

14. Document control

Revision history

---

15. Companion documents

This WISP is the umbrella program; the controls it describes are implemented and operationalized through the following companion policies and standards:

• Information Security
• Access Control Policy
• Encryption Policy
• Incident Response Policy
• Data Retention and Deletion Policy
• Vendor Management Policy
• Sub-processors
• User Acceptable Use Policy
• Employee Acceptable Use Policy
• Business Continuity and Disaster Recovery Plan
• Change Management Policy

Together with this WISP they constitute the complete information-security program of SendTax.

---

16. Contact