CAUTtools
Security

Security and data handling

Version 1.1 · Last updated 4 August 2026

CAUTtools is in limited beta. It is in daily use at a small number of institutions and is being developed alongside a small number of technicians. This page describes our posture honestly at that stage. It is not a vendor security attestation, and the commitments a subscription would carry — recovery targets, notification windows, retention guarantees — are agreed in the subscription agreement, against the environment in place at the time, rather than published here.

This page is written for the person doing your institution's vendor security review. It states our actual posture, including where that posture is thin. CAUTtools is a small vendor and we would rather you know that from this page than discover it in month three.

What we hold

Records about pianos: identity, condition, location, service history, photographs, and valuation. Accounts for the staff who maintain them. Contact details supplied by people reporting a fault. Room schedules imported from institutional calendars.

We hold no education records, no payment card data, no government identifiers, and no health information. The blast radius of a CAUTtools compromise is a piano inventory and a set of work-order contact details — real, but bounded.

Tenant isolation

Each institution gets its own subdomain and its own database with its own credentials. Tenancy is resolved server-side from the requested hostname; there is no customer-facing parameter that selects a database. Data is not pooled, joined, or aggregated across institutions, and no CAUTtools feature exposes one institution's records to another.

Encryption

  • In transit. HTTPS with TLS across all subdomains, with HTTP redirected to HTTPS. Certificates are issued and renewed automatically.
  • At rest. The service runs on shared hosting. We make no volume-level encryption-at-rest claim and none should be assumed. If your procurement process requires a documented answer, ask and we will seek written confirmation from the provider before you sign.
  • Passwords. Stored as salted one-way hashes. Never stored or logged in clear text, and never recoverable — reset only.

Access control

  • Role-based permissions separating lead technician, staff technician, contractor, administrator, and public requester.
  • Public service request submission requires no account and grants no read access to the register.
  • Administrative endpoints are authenticated and rejected for unauthenticated sessions.
  • Production access is held by one person, the operator, and is used only to run and support the service.

Single sign-on. SAML and Shibboleth integration is not available today. If your institution requires SSO, tell us during evaluation — it is the single most requested item on our roadmap and we will be straight with you about timing.

Logging and audit

The application records an audit trail of administrative actions: status changes, assignments, comments, edits, and completions, each with actor and timestamp. Service history on an instrument is append-only in practice, because the record's value is its continuity. Server and application logs are written to the institution's database, so they are retained as long as that database and are covered by the same daily backups.

Backups and recovery

  • Automated backups run daily and are currently retained for three weeks. Retention follows the hosting plan in place and is not yet a contractual guarantee.
  • Because backups run daily, at most 24 hours of work is at risk in a recovery. We do not publish a contractual recovery time objective at this stage; it is agreed in the subscription agreement.
  • Restores have been performed successfully from provider backups. We do not run a restore test on a fixed schedule.

Availability and monitoring

Automated checks run against the instrument search and service request paths and alert us on failure. We do not currently publish a status page or offer a contractual uptime SLA; institutions that need one should raise it during contracting so we can agree terms we can actually meet.

Vulnerability management

  • Dependencies are patched on a best-effort basis, and out of band for actively exploited vulnerabilities.
  • Changes go through review before deployment; deployment is automated from version control, so every production change is traceable to a commit.
  • Application inputs are parameterised at the database layer to prevent injection, and output is escaped to prevent cross-site scripting.

Independent assessment: none yet. CAUTtools has not undergone a third-party penetration test and holds no SOC 2, ISO 27001, or equivalent certification. We would rather say so plainly than imply otherwise. If your review process requires a penetration test before signature, tell us — we will commission one and share the report and remediation.

Incident response

If we confirm a security incident affecting an institution's data, we notify that institution's named contact without undue delay, and as a matter of practice within 72 hours, with what happened, what data was involved, what we have done, and what they may need to do. We support the institution's own breach notification obligations, including any required under state law.

To report a vulnerability, email hello@cauttools.com with the details. We will acknowledge within two business days. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and service degradation, and give us reasonable time to fix the issue.

Personnel

CAUTtools is operated by one person, Willis Glen Miller III, who is the only individual with production access. No contractors have access. There is no formal background-check or confidentiality-agreement programme, because there are no other personnel.

Subprocessors

Hosting: GoDaddy.com, LLC. Email delivery: GoDaddy.com, LLC. We notify customers before adding any subprocessor that handles personal data. The current list is available on request and forms part of our data processing agreement.

Your data is yours

  • The institution owns its data. We claim no rights to it beyond operating the service.
  • Export is available at any time through the admin console, in standard formats, not only at termination.
  • On termination we provide a full export, then delete the data including backups within 30 days.
  • We do not use customer data to train machine learning or AI models.

For your review process

We can supply, on request:

  • A completed HECVAT (Higher Education Community Vendor Assessment Toolkit), Lite or Full.
  • A data processing agreement, including Standard Contractual Clauses where the GDPR applies.
  • A FERPA school official addendum, if your institution prefers to designate us as one.
  • An accessibility conformance report — see the accessibility statement.
  • A data flow diagram and a current subprocessor list.

Send security questionnaires to hello@cauttools.com.