College programs entrust VeriScout with information about real, identifiable young athletes — much of it about minors. We take that responsibility seriously. This page summarises how the platform is built, hosted and operated from a security and privacy perspective, in plain terms.
It is intended for procurement teams, athletic directors and IT contacts who are evaluating VeriScout. The formal commitments live in our Privacy Policy, Data Processing Agreement and Subprocessors page.
We do not currently hold third-party security certifications such as SOC 2 or ISO 27001. The descriptions on this page reflect our actual practices today, not aspirations.
Hosting and data residency
The VeriScout platform runs on Amazon Web Services in Frankfurt, Germany (AWS region eu-central-1). Customer User and Player data is stored in the European Union by default. Day-to-day operations rely on AWS-managed services for compute, storage, networking and database; we do not run our own data centre.
AWS itself is independently certified to ISO 27001, SOC 2 and PCI DSS at the infrastructure layer. Our use of AWS does not change the data-controller relationship described in the Privacy Policy.
Data in transit
All traffic between user browsers and the VeriScout platform is encrypted with TLS 1.2 or higher. We redirect any plain-HTTP request to HTTPS automatically and reject downgraded or insecure connections to the customer portal.
Data at rest
Customer User and Player data is encrypted at rest using AES-256 at the storage and database layer through AWS-managed encryption. Encryption keys are managed by AWS Key Management Service (KMS) and are not exportable.
Authentication and access for Customer Users
Customer Users sign in to the customer portal with email and password. We:
- enforce a minimum password length and complexity;
- hash passwords with industry-standard algorithms — passwords are never stored in plain text and never transmitted in URLs or query strings;
- rate-limit failed sign-in attempts to slow brute-force and credential-stuffing attempts;
- issue session tokens that are HTTP-only, Secure, and short-lived; and
- invalidate sessions on sign-out, password change, or detected suspicious activity.
Multi-factor authentication (MFA) and single sign-on (SAML / OIDC) are on our roadmap. If MFA or SSO is a procurement requirement for your program, please tell us and we will discuss timing.
Account verification
We do not allow self-service signup. Every Customer User account is manually verified by VeriScout before activation. We confirm that the work email belongs to a recognised college program and confirm directly with the head coach or athletics administrator at that program before access is granted. This applies equally to the first user at a college and to additional staff added later.
Administrative access inside VeriScout
Internal access to production systems is restricted to a small number of named VeriScout personnel under the principle of least privilege. Personnel are bound by written confidentiality obligations and access is removed promptly when their role changes.
We log administrative actions on Customer User and Player data so that any access can be traced after the fact.
Audit logging
We maintain logs of authentication events, administrative actions, and security-relevant events on the platform. Logs are retained for a defined period for security and abuse-prevention purposes and are not used to build behavioural profiles of individual visitors. See the Privacy Policy and Cookie Policy for retention details.
Backups and disaster recovery
Customer User and Player data is backed up regularly. Backups are encrypted and access-controlled. Encrypted backups may persist for up to 35 days beyond active deletion of source data, after which they are overwritten as part of normal backup-rotation cycles. We periodically test restore procedures to confirm that backups are usable.
Software development practices
We follow secure software-development practices appropriate to a small focused team:
- code review on changes that touch authentication, data access, or database queries;
- prompt patching of known vulnerabilities in third-party dependencies;
- isolation between production, staging and development environments; and
- parameterised database queries and standard mitigations for the OWASP Top 10 categories.
We have completed an internal security review of the platform. We have not yet engaged an external penetration-testing firm; we plan to do so as the customer base grows. In the meantime, if you believe you have found a security issue, please use the disclosure path below — we will engage with good-faith reports promptly.
Incident response and breach notification
We operate a documented incident-response process covering detection, containment, eradication, recovery and post-incident review.
If we ever experience a personal-data breach that is likely to result in a risk to the rights of data subjects, we will notify the relevant data-protection authority within 72 hours and notify affected individuals where required by law. If a breach affects a specific subscribed Customer's data, we will notify that Customer without undue delay and provide the information required for the Customer to meet its own legal obligations — see Section 10 of the Data Processing Agreement.
Sub-processors and onward sharing
We use a deliberately small set of third-party services to deliver the platform. The current list is published at /subprocessors. We notify subscribed Customers by email at least 30 days before adding or replacing a sub-processor that processes Customer User or Player personal data.
We do not sell personal data, do not "share" personal data for cross-context behavioural advertising, and do not load any third-party analytics, advertising or session-replay trackers on the public site or the customer portal.
Reporting a security concern
If you have found a security issue, or you have a concern about how data on the platform is being handled, please email Hello@veri-scout.com with the subject line "Security".
We will acknowledge the message within 5 working days, work with you in good faith on a remediation timeline, and credit the reporter on request once the issue is resolved. We do not pursue legal action against good-faith security researchers who follow this disclosure path and who do not access, modify or exfiltrate data beyond what is necessary to demonstrate the issue.
What we are working towards
We are pre-GA, and we are honest about where the platform is and where it is going. The current security and trust priorities are:
- engagement of an external penetration-testing firm;
- multi-factor authentication for Customer Users;
- single sign-on (SAML / OIDC) for customers that require it; and
- a public status page reporting platform availability and incidents.
If any of these is a hard requirement for your program, tell us — we will be transparent about timing and where it sits on the roadmap.