Security
Where a K-1 goes, and what is left when the job ends
A K-1 carries a client's Social Security number, their EIN, and their capital account. Firms ask what happens to those before they ask anything about OCR. This page answers it hop by hop, and then says plainly what we do not have.
The path a K-1 takes
Five hops. At each one, the same question: right now, where does this client's document exist?
-
01
Your browser posts the file to this site's own address
The upload leaves your machine and reaches our edge. It is now in flight.
The form posts to /api/convert on k1tocsv.com — same origin as this page, so there is no third-party endpoint being offered your document. The edge function forwards the bytes to the conversion service and adds one header saying which form layout to read.
-
02
The file is handed to the reader as a stream, not as a path
In memory, inside a sandbox that exists for this job alone.
This is the part that matters most: our conversion code does not save your K-1 to disk and then read it back. It hands the bytes to the reading engine as an in-memory stream. There is no temporary file opened, so there is no temporary file to clean up, and no window in which a file with a full Social Security number on it is sitting in a directory somewhere.
-
03
Every job gets its own sandbox
A fresh instance per conversion, discarded when it finishes.
We run no always-on server holding customer files. Each conversion starts an instance, reads the K-1, and when the job ends the instance is torn down — memory and all — and the next K-1 starts a new one. Nothing from your document is carried over to the next person's job, because there is no next person's job on that instance.
-
04
The identifiers are cut down before anything comes back
Still inside our service. By the time the response is assembled, the full numbers are gone.
The reader truncates every Social Security number, TIN and EIN it finds to the last four digits, on our side, before the response is built. Every sourced line behind a box is masked the same way. A final pass sweeps the whole result before it leaves, so no identifier-shaped string can ride out unmasked. The table, the CSV, the checklist and the copyable text never contain a full number.
-
05
Nothing is kept afterwards
Nowhere.
No copy of your K-1. No copy of the text read out of it. No copy of the finished worksheet. The instance is gone, and we do not write the extraction into a cache for this site — which is a deliberate cost to us, explained below.
The cache we gave up on purpose
Most systems keep the result of a conversion for a while, so that dropping the same file in again is instant. Nothing in this product does that any more. The copy would have held the text the reader produced, before masking — which is to say your client's full Social Security number, EIN, name and capital account, sitting in storage we control, in exchange for saving one re-run. That is a bad trade for a firm that answers to §7216. So there is no second copy on our side at all.
What you may still get back is the copy saved in your own browser. Come back within the day, in the same browser, and the batch reopens from there — the figures, the page references, the ticks you made. That copy never travelled to us a second time, and we cannot see it. It is your machine holding your client's masked worksheet, which is exactly where that belongs.
Two things to know about that copy, because your own information security program has to account for it: the browser stores it in plain text rather than encrypted, so it sits under whatever controls you already apply to the machine that holds client files; and masking removes the identifiers, not the sensitivity — a K-1 is still tax return information, with names, addresses, capital accounts and ownership percentages on it. Treat the browser copy the way you would treat the paper it came from.
What you can check, and what you cannot
Two things you can verify from your own machine. One thing no machine of yours can verify, and we would rather say so than sell you a trick.
- Where the upload goes. Open your browser's developer tools, keep the Network tab open, and drop a file. One request leaves your machine, to k1tocsv.com — the same address as this page. Your browser attaches the file to nothing else. What our own service does with those bytes after they land is the hop list above, and it is not visible from your side.
- That the identifiers were cut before the response was assembled. The result you get back already has every SSN and EIN at the last four digits, and the network log shows the response arriving that way. The masking did not happen in your browser.
What we do not have
Being straight about this is worth more to a firm than a badge. K1 FastTax holds no SOC 2 Type II report and no ISO 27001 certificate. We have not been audited by an outside firm and we will not imply that we have. If your file-review checklist requires either of those, we are not the tool for that checklist, and we would rather you find out here than after a procurement call.
What we have instead is a smaller claim that happens to be checkable: the document is read in memory, the instance is discarded, the identifiers are truncated before they leave, and there is no second copy. You can put that in a written security program. You cannot put “we are a big company” in one.
What § 7216 leaves to you
It is the one statute firms ask us about by name, so it is worth being exact about it. § 7216 governs the disclosure and use of tax return information by the preparer — by the firm — and no vendor can be “certified” under it. We do not claim to be, and a page that told you otherwise would be the first thing worth doubting.
What a tool can do is take one item off the list your written program has to account for: the copy of your client's document sitting in a vendor's storage, for as long as that vendor chooses to keep it. Here there is no such copy to account for. The rest stays where it belongs — which identifiers you mask before the upload, who inside the firm may open the result, and what the client is told. This page does not answer those for you, and no tool should.
What you can do on your side
- Cover items A and E before uploading. The reader does not need the SSN or the EIN to read the amounts and the codes. Mask them out and the two fields come back empty for you to type from the form. The review list says so, so nothing is silently blank.
- Ask us who runs the compute, in writing, before you send anything. We name the infrastructure supplier to a firm that asks, and we will do it before your first upload rather than after. Write to [email protected] .
- Try it on a sample first. The built-in samples show the whole output — result, sources, checklist — without any client document leaving your machine.
A paragraph for your information security program
Firms keep a written security program and have to record what each outside service does. Here is a description you can paste into yours, and we will sign a data processing addendum that says the same thing.
K1 FastTax is used as an auxiliary service in connection with the preparation of client returns. Uploaded documents are held in volatile memory for the duration of the conversion and destroyed with the sandbox that processed them; no copy of the document, of the extracted text, or of the resulting worksheet is retained. Social Security numbers, TINs and EINs returned to the firm are truncated to the last four digits. No outside model or third-party reading service processes the document, and no uploaded content is used for training. Access is over TLS. Compute is provided by a single infrastructure supplier, identified in writing to the firm on request prior to first use.
For the addendum, or if § 7216 taxpayer confidentiality rules at your practice require all extraction to execute strictly on disconnected local preparer workstations, write to [email protected] to discuss an in-house workstation license. What happens to the file itself, in more detail, is on the privacy page ; what the product does and does not decide is in the terms .