Data Processing Agreement

1. Parties and Roles

In this agreement the Institution is the customer and TCS Platform is the Provider.

• The Institution is the controller of its data: it decides what is collected, who may see it, and how long it is kept.
• The Provider is the processor: we hold and process that data only to deliver the service the Institution has subscribed to, and only on its instructions.
• Under FERPA, the Provider acts as a school official with a legitimate educational interest in the records it processes, under the Institution's direct control. See our FERPA Compliance page.

We do not sell data, we do not use Institution data to train AI models, and we do not use it for advertising.

2. Scope of Processing

Categories of data subject: students, faculty and staff, standardized patients, and clinical preceptors.

Categories of personal data: name, institutional email address, role and programme membership, assessment results and performance records, clinical hour and encounter logs, compliance and credentialing documents the individual uploads, and in-app messages.

Special category data: compliance tracking may involve immunisation records and the results of background screening performed by a third party, uploaded by the individual as proof. These are held as documents, are visible only to the individual and authorised institutional staff, and are subject to the retention terms below.

No real patient data. Every patient in the platform is fabricated for teaching. The platform is not a medical record system and must not be used to store real patient information. See our HIPAA page.

3. Security Measures

The following are implemented today. Where a measure is partial, it says so.

• Tenant isolation enforced in the database, not the interface. Every record carries the owning organisation, and queries are scoped at the SQL layer so one institution's data cannot be returned to another, regardless of role or request.
• Role-based access control across twelve roles, with students able to see only their own records.
• Audit logging of every state change, recording the acting user, the action, the record, and the time.
• Encryption in transit for all traffic. Stored credentials and integration secrets are encrypted at rest with AES-256. Full database-level encryption at rest is a function of the hosting environment rather than the application.
• Cross-site request forgery protection applied centrally to every write, and security response headers on every page.
• No third-party origins. Application scripts, styles and fonts are served from our own domain, so page loads do not disclose user activity to external content networks.
• Soft deletion with scheduled erasure, as described in the Data Retention and Deletion policy.

Certification status, stated plainly: we do not currently hold a SOC 2 Type II report. The controls above were built to be compatible with one. Institutions requiring a completed attestation before signing should raise it during procurement so it can be addressed in the contract rather than assumed.

4. Subprocessors

We use a small number of subprocessors to deliver the service. Each is bound to confidentiality and security obligations no less protective than these terms.

• Hosting and database: our infrastructure provider, in the United States.
• Transactional email: delivery of password resets, notifications and score release messages.
• Payment processing: for institutions paying by card. Card details are handled by the processor and never reach our systems.

Optional features may involve additional subprocessors, and are off unless the Institution enables them: AI-assisted authoring tools call an external model provider with the content submitted to them, and live clinical vocabulary lookup queries public terminology services. Neither is required to use the platform. We will give notice before adding or replacing a subprocessor that processes personal data, and the Institution may object.

5. International Transfers

Data is processed in the United States. Institutions outside the United States should raise data residency during procurement; we will not represent that data stays in a region where it does not.

6. Retention and Deletion

Retention terms, what deletion means technically, and how to request erasure are set out in full in the Data Retention and Deletion policy, which forms part of these terms. In summary: the Institution controls how long its student records are kept and we never age them out on our own initiative; anything deleted in the application is permanently erased after twelve months; and on account closure data is retained for thirty days for export, then erased apart from records we must keep by law.

7. Data Subject Requests

Because the Institution is the controller, requests from individuals to access, correct or delete their records are directed to the Institution. Where an individual contacts us directly, we refer them to their institutional administrator and notify that administrator. We will assist the Institution in responding, at no charge for reasonable volumes.

8. Breach Notification

If we become aware of a breach of security leading to unauthorised access to, disclosure of, or loss of Institution personal data, we will notify the Institution's designated contact without undue delay and in any event within 72 hours of becoming aware. The notification will describe what we know about the nature of the breach, the categories and approximate volume of data involved, the likely consequences, and the steps taken or proposed. We will keep the Institution updated as the investigation proceeds and will not require the Institution to wait for a complete picture before being told.

9. Audit and Assurance

On reasonable written notice and no more than once a year, the Institution may request a summary of our security controls and the retention run records relevant to its own data. Where the Institution's own regulators require more, we will negotiate that in the signed agreement rather than refuse it here.

10. Return and Deletion on Termination

On termination, the Institution may export its data through the platform's own export tools for thirty days. After that period we erase it, other than records we are legally required to retain. We will confirm erasure in writing on request.

11. Contact

Data protection enquiries: legal@osceapp.com. Privacy and deletion requests: privacy@osceapp.com. Security reports: security@osceapp.com.