How information is kept, and how it is destroyed

This is a draft for a Colorado lawyer to review. It is not legal advice and it was not written by a lawyer.

This one is required, and it has no size threshold. Colorado Revised Statutes 6-1-713 requires any business holding personal identifying information to keep a written policy for its destruction and disposal. 6-1-713.5(1) requires reasonable security practices. Neither has a revenue test or a headcount test. A one van plumber is inside them and so is a one person agency. This is that written policy.

Last changed: 15 September 2026 Owner: Nathan Vogt, who is the only person with access to any of it.

1. What this covers

Everything Carverpoint holds that is about a person rather than about a business: client account details, the inquiries that arrive through client websites, customer lists handed to us for Reviews, and the records of who signed in and when.

It also covers paper, if any ever exists. Today none does, and the correct answer to "where are the paper files" is that there are none and that is on purpose.

2. The controls, ranked by how much risk they actually remove

Ranked rather than listed, because a list implies they matter equally and they do not.

1. Hardware security keys on the accounts that matter. The hosting account and the domain registrar. For one operator holding hundreds of businesses' data, somebody taking over that account is the highest probability catastrophic event, comfortably ahead of any flaw in the software. Two keys, one carried and one kept elsewhere, and no fallback to a text message.

2. No passwords anywhere in the product. Clients sign in with a code sent to their email. There is no password to steal, reuse or leak. The codes are stored as salted hashes and are useless within a day.

3. Session tokens stored hashed. Somebody reading the database cannot use what they find to sign in as anybody.

4. Every client kept separate, by the software rather than by care. Each client's records are scoped to their own tenant. Files in storage are keyed by tenant so that a mis-scoped read is visible in the key string during review, and there is a test that fails the build if one client's data can reach another.

5. No card details anywhere. Not a number, not an expiry, not a code, not a chargeable token. There is no database column that could hold one and no form field that could receive one, and a check fails the build if either appears. Every card is typed on Stripe's own page. That is the whole reason to use Stripe's hosted checkout rather than its programming interface.

6. No client input ever becomes raw markup. Structured values only, escaped when the page is drawn. There is exactly one function in the codebase that can emit unescaped markup, so a reviewer can find every place it is used by searching for its name, and no client supplied value goes through it.

7. Every operator sign in as a client is recorded, in a log that cannot be edited or deleted by anybody including the operator, and the client is told that this is how it works.

8. Tight rules on what a page may load. Both the public site and the client dashboard are served with a policy the browser enforces, permitting nothing from any other origin.

3. What is not true yet, said out loud

A security document that lists intentions as if they were behaviors is worse than no document, because it is a written admission on the day somebody checks.

• The automatic deletion job is written and running, and it is deliberately not deleting anything yet. It runs every night at 02:23 Mountain, it counts every category in section 5, it records what it found, and it emails the counts. What it does not do yet is destroy anything, and that is on purpose rather than by oversight. It stays a dry run until it is armed, and arming it starts a fourteen day period in which it keeps counting and still destroys nothing, so that a wrong setting announces itself before it acts rather than after. Until the arming date passes, deletion still happens when somebody asks and somebody does it by hand, and section 5 still says so.
• New device sign in alerts do not exist. The list of active sessions does, and a client can end any of them from their account page.
• The weekly database export runs, has been proved once, and is not yet on a schedule. Until August 28, 2026, the command could not start: three separate faults, each of which stopped it before it read its first argument, and none of which any test could have caught because they were in how the command was launched rather than in what it checks. That is now fixed and both halves have been run for real on a copy of the database: a dated copy written that nothing can overwrite, a size check against the last one that passed, and a second command that loads the copy back into an empty database and asserts it is one you could serve from. Every table came back identical. Two deliberately damaged copies were both refused. What is still missing is a machine that runs the first command every week without being asked, and the fact that neither command has yet been run against the live database, because there is no client data in it yet. Until both are true, the export happens when somebody runs it, and the thirty days of automatic point in time recovery the database provides on its own is the layer that is genuinely always on.
• The weekly copy covers the database and not the files. Everything a client typed and every inquiry they received is in it. Photographs and video they uploaded are held in one place, and the storage they sit in does not keep previous versions of a file, so an overwritten or deleted one is gone. Clients are told to keep their own originals, in section 4 of the agreement, in those words. This is a real gap and it is named here rather than covered by the word "backups".
• There is no written break glass procedure. If the operator is in hospital, nobody knows who holds the credentials or how several hundred businesses keep receiving their inquiries. That is a real obligation to clients who depend on it, and sophisticated buyers ask about it.

Each of those is on the list in ../CARVERPOINT-LEGAL.md. None of them may be described as done, in a contract or on a sales call, until it is.

4. Destruction and disposal, which is the part the statute asks for

Electronic records. Deleted from the live database and from backups on the schedule in section 5, or on request, whichever comes first. Deletion means the record is gone rather than hidden. Where a record is kept deliberately, section 5 says which and why.

Files and images. Removed from storage by tenant prefix, which deletes every file belonging to one client in a single operation.

Backups. The database's own point in time recovery holds thirty days and then expires by itself. Weekly copies taken off the hosting provider are held for ninety days and then deleted automatically by a rule on the storage they sit in, so nobody has to remember. Any copy held anywhere else is destroyed on the same schedule as the data in it. A record is deleted from the live database first; the copies age out behind it, which means for up to ninety days after a deletion the record still exists in a backup nobody can read without the operator's own credentials. That is stated rather than glossed, because it is true of every backup anybody has ever taken and pretending otherwise is how a privacy notice becomes false.

Devices. Any laptop, phone or drive that has held client data is wiped with the operating system's own full disk erase before it leaves the operator's possession, and drives that cannot be wiped are physically destroyed rather than sold.

Paper. If a printed customer list, a signed agreement or a note carrying somebody's details ever exists, it is cross cut shredded when it is no longer needed. Not put in a bin. Not put in a recycling box.

Anything sent by a client that we did not ask for. Deleted rather than filed. If a client emails a spreadsheet with more columns than the job needs, the extra columns are dropped before anything is stored, and the original email is deleted once the useful part has been taken out of it.

5. How long things are kept

Every number in that table is the number the job uses, and the job is armed. It is written, and on August 27, 2026, it was run against a copy of the database holding rows old enough to delete: it counted every row in this table correctly, and in dry run it destroyed none of them. Then it was armed on that copy and it destroyed exactly the rows that were past their date, leaving behind the two that a careless version would have taken.

On August 28, 2026, it was armed on the live database, and section 8 required that to happen in the same commit that took the "by hand today" markers off the rows above, which is this one. The day it was armed is part of the argument: this business received its first two inquiries that same day, so on the day the destroying job was switched on there was nothing old enough for it to destroy, and there will not be for ninety days. A job like this is armed when it is harmless or it is armed against a backlog, and the second is how a mis-set number takes a client's whole history in one night.

Being armed is still not the same as destroying. The first live run writes an arming date fourteen days out and reports its counts every night until then, and either of two commands ends the countdown without a deploy: one brings it forward, one stops it for good. Two caps refuse a whole run rather than a part of it, at two thousand rows across the business or twenty percent of any one client, because a partial destruction is harder to reason about afterwards than none at all.

6. Who else touches anything

The list is at subprocessors.md and it is dated. Each of them is bound in writing to protect what they touch, and adding one is a thing clients are told about before it happens rather than after.

7. When something goes wrong

breach-response.md. It exists, it names who is called in what order, and it is built around the thirty days Colorado gives you rather than around finding out what the deadline is while the clock runs.

8. Reviewing this document

Once a year, and immediately on any of these:

• A new company joins the subprocessor list.
• The product starts holding a kind of information it did not hold before.
• Any of the five things in section 3 stops being true, in which case the line moves out of section 3 and into section 2 in the same commit. There were four when this line was written and the count is now checked against the list rather than remembered.
• Anything in section 5 becomes automatic, in which case the "by hand today" marker comes off and the table becomes quotable. The deletion job being armed is that event, and the person who arms it edits this table in the same sitting, having first read what the job says it is about to destroy.
• An incident, whether or not it turned out to be anything.

9. Honest limits

"Reasonable security procedures" has no defined content in the statute. It says appropriate to the nature of the information and the size of the business. There is no safe harbor and no checklist to pass. What is described here is well above what a solo operator typically does. Nobody can say it is sufficient, and this document is not going to pretend otherwise.

Everything above rests on one person. That is the honest risk and it is why item 1 in section 2 is item 1 and why the missing break glass procedure in section 3 matters more than it looks.