Trust

Security and privacy

A tax return is the most concentrated file of personal information most people will ever hand over. This page describes the mechanisms we use to protect it — not badges, not logos, and not certifications we have not been granted.

Written for preparers and for the taxpayers they serve. If something here is unclear or looks wrong, tell us and we will fix the page.

Scope

What is actually at stake

Before the controls, the inventory. These are the categories of information the software holds, and everything below is written in terms of them.

Source documents: Wage and income statements, retirement and brokerage forms, tuition statements, mortgage interest statements, and anything else a taxpayer uploads. Images and PDFs, often photographed on a phone, often containing more than the form itself.
Identifiers: Social Security and taxpayer identification numbers for the filer, a spouse, and every dependent. Employer identification numbers. Dates of birth. Preparer identification numbers.
Bank details: Routing and account numbers, where a taxpayer has asked for a direct deposit or an electronic payment. Held only for the return they belong to.
The return itself: Every figure on the 1040, the PA-40, the supporting schedules, and the diagnostics raised against them — which together describe a household in more detail than the documents did.
Signatures and authorizations: Form 8879 authorizations and the audit trail behind them: who signed, from where, and when.
Correspondence: Messages between a taxpayer and a preparer inside the portal, and the notes a preparer records against a return.

In transit and at rest

Encryption

Every connection to the application is served over HTTPS. The site is delivered with HTTP Strict Transport Security, so a browser that has visited once will refuse to fall back to an unencrypted connection afterwards, and modern TLS is required — the older protocol versions are not offered at all.

Uploaded documents are written to object storage with server-side encryption enabled; the database that holds return data and identifiers is encrypted at rest, as are its automated backups. Encryption keys are held in the hosting platform’s managed key service rather than in application configuration, which means no key is ever checked into a repository or printed by a deployment script.

Encryption at rest protects a stolen disk or a mislaid backup. It does not protect against a valid login being misused, which is why most of this page is about access rather than about ciphers.

Masking

You will rarely see a full Social Security number

Identifiers are treated as write-once, read-almost-never. The interface is built so that the full number appears in the smallest number of places we can manage, and nowhere at all in the places that get copied, exported or emailed.

When a taxpayer or a preparer types an identifier, it is visible in the field while they type — hiding it there only produces transcription errors. The moment the field loses focus, the value masks to its last four digits and stays that way for the rest of the session.

Everywhere else, the last four digits are the identifier. Client lists, search results, review screens, diagnostics, and the views our own people would use to help you all render ***-**-6789 and nothing more. Search is built to accept the last four, so that nobody ever needs to reveal a full number in order to find a record.

Identifiers are never written to application logs, never placed in a URL or a query string, never sent in the body of an email or a notification, and never included in an exported list. The full value is decrypted only where it must appear: on the return document itself and in the electronic filing sent to the taxing authority.

The same number, in three places

While it is being typed: 123-45-6789
Everywhere in the interface afterwards: ***-**-6789
Application logs, exports, notifications: [redacted]

The number above is a fictitious example, not a real identifier.

Who can see what

Role separation and least privilege

There are four roles, and they are enforced on the server for every request. Hiding a link in a menu is a courtesy, not a control, and we do not treat it as one.

Preparer: Works on the returns assigned to them. Sees the clients on those returns and nobody else’s.
Reviewer: Reads a return in full and signs off, or sends it back with notes. Review is a separate role precisely so that the person who prepared a return is not the person who approves it.
Administrator: Manages users, roles and practice settings, and can read the audit history. An administrator can grant access; they cannot grant it silently.
Client: Sees their own return, their own documents and their own filing status. Nothing else exists as far as their session is concerned.

Alongside the roles:

Every person has their own credentials. Shared logins are not supported, because an audit trail with a shared account in it answers no useful question.
Sessions expire after a period of inactivity and can be ended remotely by an administrator.
Access to a practice’s data by us, for support, requires an explicit grant from that practice, is scoped to what was asked about, and is recorded in the same audit history the practice reads.
Removing a person from a practice revokes their sessions, not just their next login.

Access logging

Reads are recorded, not only writes

Most systems log changes. In a tax practice, the more revealing question is usually who looked. Every view of a return, every opening of an uploaded document, every export and every authorization event is written to an access log with the acting user, the record touched, the action, and the time.

The log is append-only by design: the application offers no route to edit or delete an entry, and administrators and reviewers can read the history for their own practice without asking us for it. Entries carry masked identifiers only, so the audit trail never becomes the easiest place to harvest the data it exists to protect.

What this gives a practice

If a client asks who has seen their file, that is a question a practice can answer for itself, from a screen, in about a minute.

Boundaries

What leaves the system, and what does not

What leaves

The return and its schedules, transmitted to the taxing authority through the electronic filing channel, when a taxpayer has authorized it.
Transactional email — a document request, a signature request, a filing status change. These carry no identifiers and no figures, only a note that something is waiting.
Aggregate, non-identifying operational metrics we use to keep the service up: error rates, response times, queue depths.

What does not

Return data and documents are not sold, rented, or shared for anyone else’s marketing. Not to lenders, not to insurers, not to advertisers.
Client documents and return figures are not used to train machine-learning models.
There is no advertising pixel, no third-party analytics tag and no session-replay script on the public site or in the product. Typefaces are self-hosted, so even a font request does not disclose your visit to anyone.
Identifiers never appear in logs, exports, notifications or URLs — see the masking section above.

We use a small number of infrastructure providers: cloud hosting and database, object storage for documents, transactional email, and the channel that carries an electronic filing to the taxing authority. They are bound by contract to process data only on our instructions. A current list is available on request — write to tax@ghimtech.org and ask for it.

Separately, federal law limits what a tax return preparer may do with return information at all. Disclosing or using it for anything other than preparing the return generally requires a specific, written, informed consent from the taxpayer, and that is the standard we hold ourselves to whether or not a particular activity would fall inside it.

Lifecycle

Retention and deletion

A tax practice cannot simply delete records on request: preparers carry their own record-retention obligations, and a return that disappears the week before an examination helps nobody. So retention is set by the practice, within the limits those obligations impose, rather than by us.

What that means in practice:

A practice sets a retention period for completed returns and their source documents. The default is the longest period its professional obligations require, not the shortest.
Once the period elapses, records are purged on a schedule rather than lingering indefinitely in a bucket nobody looks at.
A taxpayer can ask for their documents to be deleted. Where a retention obligation does not prevent it, the record is removed from live systems promptly and disappears from backups as those backups age out of their own rotation — we do not surgically edit backups, and any policy claiming otherwise should be read sceptically.
Closing a practice’s account triggers an export first, so that nobody loses records they are legally required to keep.

When something goes wrong

Incident response

We maintain a written incident response procedure covering detection, containment, assessment and notification. If personal information held in the service is exposed, we will tell the affected practice without unreasonable delay, describe what we know and what we do not yet know, and say what we are doing about it. Where Pennsylvania’s breach notification statute or another applicable law sets a specific requirement, we follow it.

We would rather send an early notice that turns out to be smaller than feared than a polished one that arrives a month late.

Plainly

What we do not claim

This is the part of a security page most companies leave out, which is exactly why it is worth reading.

We hold no security certification or third-party attestation that we have not been granted, and this page displays no badge suggesting otherwise. If you require an independent audit report before you can adopt software, ask us where we stand and we will answer honestly rather than point at a logo.
We cannot guarantee that any return will be accepted for electronic filing, that any refund will arrive, or that a return prepared with this software will not be examined. Nobody can guarantee those things, and a vendor who says they can is telling you something about their other claims.
Encryption, logging and role separation reduce risk. They do not eliminate it. A stolen password with a valid session behind it defeats a great deal of good engineering, which is why per-user credentials and access logging matter more here than any single cryptographic detail.

Responsible disclosure

Found a weakness? Tell us

Write to tax@ghimtech.orgwith “Security” in the subject line. Please include what you found, how to reproduce it, and what you think the impact is. If you need to send something sensitive, say so first and we will arrange a better channel than email.

We will not pursue legal action against anyone who reports a problem in good faith, gives us a reasonable opportunity to fix it, and does not access, alter or exfiltrate data belonging to another person while investigating. Please do not test against real taxpayer data — ours or anyone else’s.