As at 03.09.2026 · Version 1.0 · FCO SRL, operator of Dance Master Pro
0. Two architectural decisions that set the level of protection
A separate database per customer. Every dance school has its own physically separate database. There are no shared tables holding several schools’ data side by side; a separate credentials database maps accounts to schools. Mixing one school’s records with another’s is structurally impossible rather than merely prevented by filtering logic.
Documents stay with the customer. Invoice PDFs, medical certificates, photos and videos are not stored on our servers. They are transferred, over a connection the customer establishes with its own account, directly into the customer’s own cloud storage (Google Drive, Dropbox or Microsoft OneDrive). What remains on our systems is: the administrative data in the database (invoice number and amount, certificate expiry date, gallery title); for photo and video galleries, small preview images held in a directory outside both web roots, reachable through no guessable address and served only after a successful permission check; and attachments the customer itself adds to the online enrolment form.
Full-size images and videos are served either through a short-lived link freshly generated by the storage provider for each request, or streamed through our server. In both cases the files in the customer’s storage stay private: no public sharing link is created.
1. Confidentiality
1.1 Physical access — implemented. We run no data centre of our own. The service is operated at DigitalOcean’s Frankfurt facility (FRA1); physical security, surveillance, visitor management and fire protection are the operator’s responsibility, and its ISO 27001 and SOC 2 Type II certifications are available on request. No hardware holding customer data is kept on our premises.
1.2 Logical access — personal accounts only, no shared logins (implemented); passwords stored only as cryptographic hashes (implemented); administrative server access by SSH key pair with password authentication disabled (implemented); named-person access list maintained and revised immediately when someone leaves (implemented).
1.3 Authorisation — implemented. Role model of administrator, office, teacher and family access, each seeing only what its task requires. Areas not enabled are blocked server-side, not merely hidden in the interface. Individual functional areas — medical certificates, for instance — can be switched off entirely per school, after which the corresponding data is neither collected nor displayed. In the family portal a parent sees only the children linked to them, and every request for a specific item is checked individually against permissions, including when an address is called directly.
1.4 Separation — implemented. Separate database per customer, see section 0. Test and production environments are separate; real customer data is not used for testing.
1.5 Pseudonymisation and encryption — all connections TLS encrypted, unencrypted requests redirected (implemented); credentials for the customer’s mail server stored encrypted (implemented).
2. Integrity
2.1 Transmission — implemented. Encrypted transfer only; documents are not staged on our systems but written straight to the customer’s storage; no removable media, no disclosure to third parties beyond the subprocessors in Annex 3.
2.2 Input — email dispatch logged with recipient, time and delivery status (implemented); gallery access logged with user, item and time (implemented); payment and invoicing operations individually traceable (implemented).
3. Availability and resilience
Daily automatic backups of the entire server, including all databases, are taken by our infrastructure provider (DigitalOcean). They are held in the same Frankfurt am Main data centre under the provider’s retention rules and do not leave the European Union, and allow the complete system state of a calendar day to be restored (implemented). Redundant power, cooling, network and fire protection provided by the data centre operator (implemented). Continuous availability and health monitoring (implemented). Prompt application of security updates to the operating system and components in use (implemented).
4. Regular review and evaluation
4.1 Data protection management — implemented. Record of processing activities under Art. 30(2) GDPR maintained; all staff and contractors bound to confidentiality in writing; data protection and information security training on joining and annually thereafter; review of these measures at least annually and whenever something material changes.
4.2 Incident handling — implemented. Reporting channel security@dancemasterpro.com, open to external reports and published at /.well-known/security.txt. Documented sequence: record, assess, contain, notify the controller within 48 hours, follow up. Every incident is logged, including those that are not notifiable.
4.3 Supplier control — implemented. Subprocessors selected on suitability and evidence, Art. 28 GDPR agreements with all of them, annual review, list published (Annex 3).
4.4 Data protection by design and by default (Art. 25 GDPR) — implemented. Functional modules can be switched off individually, and data categories that are not needed are then never collected. Galleries are created unpublished and with no permission at all; they become visible only when the school actively sets a rule. Before a gallery is published, the number of reached pupils with no consent on file for image publication is shown. We never alter permissions in the customer’s cloud storage and never create public sharing links.
5. Deletion
Individual data subjects can be deleted by the controller in the application at any time. After the contract ends: access blocked, 30 days in a blocked state, then return or permanent deletion at the controller’s choice, extending to backups at the end of the backup cycle, confirmed in writing on request. Documents in the customer’s cloud storage are unaffected and remain under the customer’s sole control. Log data is not kept longer than is necessary for security and error analysis.
6. Certifications
FCO SRL is not currently certified to ISO/IEC 27001. Our data centre and infrastructure provider is, and we make the relevant evidence available on request. We state this openly rather than imply a certification we do not hold.
7. Changes
This annex is kept up to date. The version published at https://dancemasterpro.com/en/tom/ applies; customers are informed of material changes on request.