Security

01Our Approach

StallWise Technologies LLC builds software that holds medical records, prescriptions, controlled-substance logs, payment references, and the personal information of the people who care for horses. We treat every one of those records as sensitive, whether or not a particular regulation requires it.

This page describes the controls that are actually in place today, product by product where they differ, and names the things we have not done yet. Our platform has been through structured internal security audits whose findings are tracked to closure, and our controls are mapped to the HIPAA Security Rule and the SOC 2 trust criteria. We have not yet commissioned a third-party penetration test or a SOC 2 or ISO 27001 attestation; both are on our certification roadmap, and we will update this page when they are complete. Control documentation and audit summaries are available to prospective customers under a non-disclosure agreement.

02Platform Architecture

• Tenant scoping on every request. Every record belongs to a practice, pharmacy account, barn, or breeding operation, and every API request is checked against the signed-in user's organization before data is returned or changed. In VetPro the shared data layer also refuses to run a query without a practice context.
• Per-practice encryption keys in VetPro. Each practice's designated sensitive fields are encrypted with that practice's own data key, wrapped by a master key held outside the database. Keys can be rotated or destroyed per practice, which lets us cryptographically shred a practice's protected fields on request.
• United States hosting. Production systems, object storage, and backups are hosted in data centers located in the United States, operated by providers with physical access controls and redundant power and network.
• Separate environments. Development, staging, and production run as separate installations with separate databases and credentials. Changes are deployed to staging first and promoted to production by a scripted deploy.
• Offline-capable clients. VetPro continues to work in barns and on farm calls without connectivity, and the Barn Management mobile app queues entries made offline. Downloaded patient-history packets in VetPro are encrypted on the device; queued entries rely on the device's own lock and storage protections and sync as soon as a connection returns.

03Data Protection and Encryption

• In transit. All connections to the Services use TLS 1.2 or higher. Plain HTTP is redirected, and HTTP Strict Transport Security is enabled on every product host.
• At rest, by product.
  • VetPro: designated sensitive fields (patient conditions, medications, allergies, insurance and emergency-contact details, appointment reasons and notes, and client contact details) are encrypted with AES-256-GCM using a per-practice key. SOAP notes, lab results, and invoices are protected by access controls, tenant scoping, and encrypted backups rather than field-level encryption.
  • EquineVetRx: prescription clinical fields, pharmacist notes, DEA registration numbers, authenticator secrets, prescription documents, and PDMP files are encrypted with XChaCha20-Poly1305 using a per-record key wrapped by a master key.
  • Barn Management and BreedingPro: uploaded documents and images are encrypted at rest by our object-storage provider. Database fields are protected by access controls and tenant scoping; field-level encryption is on the roadmap.
• Key management. Master keys are stored in restricted files outside the database and outside source control, and access to them is limited to the application service account. Key rotation is supported through operator tooling and performed on demand rather than on a fixed schedule.
• Tamper-evident ledgers. EquineVetRx writes controlled-substance activity and its audit log to append-only tables in which each row is hashed together with the previous row, and database triggers block updates and deletes, so any alteration breaks the chain and is detectable. VetPro keeps an append-only controlled-substance logbook with running balances and witness fields.
• Payment data. Wherever payments are taken, card details are collected directly by Stripe, a PCI DSS Level 1 service provider. Our systems store only Stripe references and the last four digits, never full card numbers.
• Backups. VetPro database and file backups are encrypted on the server with a key held separately from the storage bucket, then uploaded to off-site object storage and retained for 30 days. Barn Management backups are taken nightly and currently stored on the application server; moving them to encrypted off-site storage, and adding scheduled backups for BreedingPro, are in progress.

04Identity and Access Control

• Multi-factor authentication. VetPro supports time-based one-time passcodes with single-use backup codes, and MFA is enforced for administrator, practice manager, and veterinarian roles, with practices able to require it for additional roles or individual users. EquineVetRx supports authenticator apps and passkeys and requires a fresh MFA check before any controlled-substance approval or dispensing. Barn Management and BreedingPro do not yet offer MFA; it is on the roadmap.
• Password protection. Passwords are hashed with bcrypt. VetPro enforces minimum length and complexity and locks an account after five failed attempts. EquineVetRx locks sign-in after five failures. Barn Management rate-limits sign-in attempts by network address.
• Session security. VetPro sessions use Secure, HTTP-only, same-site cookies, expire after 15 minutes of inactivity, and are regenerated at sign-in and periodically thereafter. Barn Management and BreedingPro issue bearer tokens that are stored hashed on the server and expire automatically; disabling a staff login revokes its tokens.
• Role-based access. VetPro provides administrator, practice manager, veterinarian, technician, and front-desk roles plus a separate client portal; Barn Management provides administrator, manager, staff, barn-staff, and viewer roles plus an owner portal; EquineVetRx separates administrator, veterinarian, pharmacist, and pharmacist-in-charge; BreedingPro provides administrator, manager, and viewer. Staff roles are denied anything not explicitly granted.
• StallWise staff access. Access to production systems and customer data is limited to a small number of named operators for support, deployment, and incident response. There is no customer-impersonation feature. Time-boxed, individually logged support access is on our roadmap.

05Audit Logging and Monitoring

Accountability is a regulatory requirement for veterinary and pharmacy records and a core design principle for us. Coverage today:

• VetPro logs sign-ins, failed attempts, lockouts, and sign-outs; views of patient records, SOAP notes, lab results, and imaging; role-permission changes; and selected exports. Practice administrators can review the security log in the application.
• EquineVetRx writes a hash-chained audit log for every regulated action: prescription status changes, protected-field reads, dispensing, rules overrides, PDMP submissions, and MFA step-ups. Database triggers prevent audit rows from being changed or deleted, and the chain can be verified from the admin console.
• Barn Management records every successful create, update, and delete through its API with the acting user, and keeps a log of every SMS sent. BreedingPro records creates, updates, and deletes on farm records and shows a recent-activity feed and per-record history in the app.
• Monitoring. VetPro production is checked every ten minutes by an automated smoke test, and a daily check verifies that backups completed, disk and certificates are healthy, and the application responds. Failures email our engineering team. We do not yet run behavioral anomaly detection; the groundwork for it exists in VetPro and is not enabled.

06Secure Development

• Secure coding controls including input validation, parameterized database queries, output encoding, CSRF tokens on form and API writes, Content Security Policy and related browser security headers, and sign-in throttling or lockout on every product. The public APIs enforce per-key rate limits.
• Automated checks. Continuous integration runs syntax checks and the unit test suite on every push to the VetPro repository, and static analysis runs nightly on BreedingPro. We are a small engineering team, so changes are reviewed by the lead engineer rather than through a multi-person peer-review gate. Expanding static analysis and adding automated dependency vulnerability scanning across all codebases are current priorities.
• Internal security audits. We run structured, evidence-based security audits of the codebases (most recently June 2026) and track every finding to closure by severity. A third-party penetration test has not yet been performed and is planned ahead of formal certification.
• Infrastructure hardening. Operating-system patches are applied on a regular, near-daily cadence. Administrative SSH access is key-based only, with password authentication disabled. Secrets live in environment files outside the web root and outside source control.

07Availability and Resilience

• Backups. VetPro's production database is backed up nightly and its files daily, encrypted, and stored off-site with 30-day retention; completion is verified every morning. Barn Management is backed up nightly to the application server. BreedingPro scheduled backups are being added.
• Restore drills. We rehearse full restores of VetPro production backups into an isolated environment. The most recent drill recovered all 367 production tables.
• Recovery objectives. Our current targets for VetPro are a 24-hour recovery point and a 4-hour recovery time. Enterprise agreements state the objectives that apply to that customer.
• Maintenance. Work that could affect availability is scheduled outside typical clinic hours with advance notice.
• Offline continuity. Because VetPro works offline, practices can keep seeing patients during an internet outage at the clinic or in the field.

08Compliance and Regulatory Alignment

09Shared Responsibility

Security works best when it is a partnership. We secure the platform; our customers secure their use of it. We recommend that every customer:

• turn on multi-factor authentication wherever it is offered, and especially for administrators and prescribers;
• assign the least-privileged role that lets each person do their job, and remove access the same day a staff member leaves;
• review the audit log and user list regularly;
• keep devices updated, use screen locks, and enable device encryption, particularly on tablets and phones used in the field;
• confirm requests to change bank or payment details through a second channel before acting on them; and
• report lost devices or suspected account compromise to us immediately so we can revoke sessions and investigate.

10Incident Response and Breach Notification

We maintain a written incident-response procedure: suspected incidents are triaged by severity, contained, investigated to root cause, and reviewed afterwards so that the fix is permanent. Every suspected incident is tracked to closure.

If we confirm an incident that affects a customer's data, we notify the customer's administrators without undue delay, provide the facts they need to assess their own notification obligations, and keep them updated until the matter is resolved. We support customers' obligations under HIPAA, state breach-notification laws, and the GDPR, including the GDPR's 72-hour supervisory authority deadline where it applies.

To report a suspected incident affecting your account, email [email protected] with "Security" at the start of the subject line. Enterprise customers receive an escalation path for urgent issues.

11Responsible Disclosure

We welcome reports from security researchers and customers who find a vulnerability in our websites or products.

How to report

• Email [email protected] with a subject line starting with [SECURITY].
• Include a description of the issue, the affected URL or product, steps to reproduce, and your assessment of impact. Proof-of-concept detail is helpful; working exploits against production data are not.
• Tell us how you would like to be credited, or whether you prefer to remain anonymous.

What we commit to

Ground rules and safe harbor

• Test only against accounts you own or a trial account you created. Never access, modify, or exfiltrate another customer's data. If you encounter it accidentally, stop and tell us.
• Do not run denial-of-service tests, automated scanners at high volume, social engineering, or physical attacks.
• Give us a reasonable time to fix the issue before disclosing it publicly.
• Research conducted in good faith under these rules is authorized. We will not pursue legal action against researchers who follow them, and we will work with you if a third party raises concerns.

We do not currently operate a paid bug bounty program. We do credit researchers who report valid issues, with their permission.

12Security Contacts and Documentation

Enterprise prospects can request our control documentation, architecture overview, and a summary of our most recent internal security audit under a non-disclosure agreement.