Technical and Organisational Measures (TOM)

1. Scope and Setup

• Company: CreatorFlow Labs S.L., Madrid, Spain. A small, fully remote team. We do not operate our own servers, server rooms or a corporate office network, and no personal data is stored on company premises.
• Hosting: The entire service runs on Amazon Web Services (AWS) in the European Union, region eu-west-1 (Ireland). Application, databases, caches, object storage and backups all reside in that region.
• Data processed: Instagram usernames and public profile identifiers, the text of comments and direct messages that trigger or result from automations, email addresses collected through automations, link-click events, and customer account and billing data. No special categories of personal data under Art. 9 GDPR are intended to be processed.
• Shared responsibility: Physical and environmental security of the data centres is provided by AWS; everything from the operating system upwards is operated by CreatorFlow. Each section below states which side a control sits on.

2. Physical Access Control (Zutrittskontrolle)

• Company premises: Not applicable. No servers, network equipment or data carriers holding personal data are located at CreatorFlow premises. Lockable server rooms, server cabinets, key management, visitor logs, alarm systems and rules for cleaning or maintenance staff therefore do not apply to us.
• Data centres (AWS): Inherited from AWS. AWS data centres implement perimeter security, badge and biometric access control, visitor escorting, CCTV, and access logging. These controls are audited under ISO 27001 and SOC 2, and the reports are available to customers on request through us or directly via AWS Artifact.
• Emergency power and fire protection: Inherited from AWS. Data centres operate redundant power feeds, uninterruptible power supplies and generators, and automatic fire detection and suppression, covered by the same audit reports.

3. System Access Control (Zugangskontrolle)

• Customer authentication: Customers sign in with an email address and password, or with Google sign-in. The signup form requires passwords of at least 8 characters; this minimum is currently enforced in the browser only, not server-side. Passwords are stored as salted hashes, never in plain text; migration to a modern password-hashing algorithm (bcrypt or argon2) is tracked as an open item. New accounts are created after a reCAPTCHA check; email confirmation before first use is not currently enforced.
• Sessions: Sessions are stored server-side and referenced by a signed cookie with the HttpOnly flag, scoped to our domain, that expires after 7 days. The Secure flag is not yet set on this cookie; adding it is on our security roadmap. Changing a password ends the current session and revokes remember-me tokens, but does not currently end other active sessions on other devices. An administrator-initiated change of the account email address invalidates all of that user's sessions.
• Account lockout: Automatic account lockout after repeated failed login attempts is not yet in place; additional login-abuse protections are on our security roadmap. Password reset links are sent only to the email address on file for the account.
• Instagram access: We never ask for or store Instagram passwords. Instagram accounts are connected through Meta's official OAuth 2.0 flow, and the resulting access tokens are encrypted at application level (AES-256) before storage.
• Staff and infrastructure access: Access to the AWS console, servers and administrative functions is limited to named personnel with individual credentials; server access uses SSH with individual keys. Administrative functions inside the application are restricted to a single allow-listed administrator account and are rate limited.

4. Data Access Control (Zugriffskontrolle)

• Tenant scoping: Every customer record (automations, contacts, activity, analytics) is stored with the identifier of the workspace it belongs to, and the application only presents a user with the workspaces they are a member of. Server-side workspace-membership checks are in place on part of the API and are being extended to every workspace-scoped endpoint; until that is complete we do not describe tenant separation as fully enforced at the API layer.
• Need to know: Only named personnel who operate the service can access production data, and only for support, incident handling and maintenance.
• Credential protection: Instagram access tokens are encrypted at rest and excluded from default database reads, so they are not returned by ordinary queries or exports.
• Payment data: Card details are handled entirely by Stripe; CreatorFlow never receives or stores full card numbers.

5. Transfer Control (Weitergabekontrolle)

• Encryption in transit: Connections between users and the service, and between the service and Meta, Stripe, and our email and logging providers, are encrypted with TLS.
• Sub-processors: Personal data is shared only with the sub-processors listed in Section 5 of the DPA, under data processing terms. Data is hosted and logged in the European Union; transfers to sub-processors outside the EU rely on Standard Contractual Clauses or the EU-US Data Privacy Framework as set out in the DPA.
• Exports: Customers can export their collected contacts as a CSV file. Once exported, that data is under the customer's control and responsibility.
• Removable media: Not applicable. No removable data carriers (USB drives, external disks, backup tapes) are used for personal data, so no data-carrier inventory is required.

6. Logging and Input Control (Eingabekontrolle)

• Application logs: The application writes structured logs for every processed webhook, automation run, message send and API request, each carrying a correlation identifier so a single event can be traced end to end.
• Access logs: The HTTP layer records one access-log line per request.
• Central storage and retention: All logs are shipped to an EU-hosted logging platform (New Relic, EU data region) and retained for 30 days. Logs cannot be edited by application users.
• Administrative audit log: Actions performed by CreatorFlow staff on customer accounts through the administration interface, including account deletions and account email changes, are written to an audit log with the acting administrator, timestamp and outcome.
• Failed logins: Failed customer login attempts are not currently written to a dedicated security log; this is on our security roadmap.

7. Separation Control (Trennungskontrolle)

• Customer separation: Customer data is logically separated by workspace identifier at the data layer (multi-tenancy). Customers cannot see data belonging to other workspaces through the application.
• Functional separation: Account and authentication data are held in a separate database from application data (automations, contacts, analytics).
• Environments: Automated tests run against an isolated in-memory database and never touch production data. Day-to-day development uses local databases; named personnel also query production data directly for support, debugging and incident investigation. There is a single production environment and no separate staging environment; changes are verified locally and by the automated test suite before release, and can be rolled back.
• Physical separation: Not applicable beyond the AWS account boundary; all workloads run in a dedicated AWS account owned by CreatorFlow.

8. Availability and Resilience (Verfügbarkeitskontrolle)

• Infrastructure: The service runs in a single AWS region (eu-west-1) inside an auto-scaling group that automatically replaces a failed compute host. Data lives on persistent storage volumes that survive host replacement.
• Snapshots: Volume snapshots are taken before infrastructure changes and retained within the same AWS region. Snapshots that may contain personal data are deleted on rotation.
• Webhook resilience: Meta redelivers Instagram webhooks for a period after a temporary outage, and Stripe retries billing webhooks for several days, so short interruptions do not lose events.
• Monitoring: Application health, throughput and error rates are monitored through our logging platform; deployments are observed against a pre-deployment baseline.
• Limits: There is no multi-region failover and no formally committed recovery time or recovery point objective. The service is not intended for use cases that require guaranteed continuous availability.
• Data centre resilience: Inherited from AWS (redundant power, cooling and network, fire suppression), see Section 2.

9. Patch and Change Management

• Change process: Non-trivial changes start with a written specification and implementation plan. Code is covered by an automated test suite that runs against isolated test databases, and every release is built and type-checked before deployment.
• Releases: The application is deployed as versioned container images. A previous image can be redeployed to roll back a release. Higher-risk behaviour ships behind feature flags that can be switched off without a redeploy, and can be enabled for a subset of workspaces first.
• Verification: Key metrics are captured before a deployment and compared afterwards to detect regressions early.
• Dependencies and operating system: Third-party dependencies and container base images are updated through the normal release process, and the host operating system is refreshed when the compute host is replaced. There is no fixed calendar patch cadence; security-relevant updates are prioritised by severity.
• Security register: Findings from our own security audits are tracked in an internal register with a severity score and are remediated in order of risk.

10. Incident and Breach Handling

• Contact: Security concerns can be reported to security@creatorflow.so. We acknowledge reports and investigate them; we do not operate a paid bug bounty programme.
• Handling: Incidents are investigated using the central logs, contained, documented with a timeline and root cause, and remediated. Lessons learned feed back into the security register.
• Customer notification: If a personal data breach affects a customer's data, we notify that customer without undue delay after becoming aware of it, with the information described in Section 8 of the DPA, so the customer can meet its own obligations under Art. 33 and 34 GDPR.

11. Organisational Measures

• Confidentiality: Personnel with access to personal data are bound by contractual or statutory confidentiality obligations.
• Access lifecycle: Access to infrastructure and administrative functions is granted individually and removed when a person leaves or changes role.
• Devices and remote work: The team works remotely. Production data is accessed only through individual credentials over encrypted connections (TLS, SSH) and is not stored on local devices as a matter of practice. There is no corporate office network, so a VPN is not used; every administrative connection is individually authenticated and encrypted.
• Clean desk and paper records: Not applicable in the classic sense: personal data processed through the service exists only in electronic form within AWS, and no paper records of customer data are kept.
• Third parties and maintenance: No external maintenance, cleaning or support staff have access to production systems. Remote maintenance by third parties is not used; infrastructure is operated by CreatorFlow personnel only.
• Endpoint protection on servers: Production workloads run as Linux containers under non-root users on a host that exposes only HTTPS publicly; employee workstations are not part of the production network.

12. Deletion and Retention

• Account deletion: On request, an account is deleted together with all of its workspaces, automations, contacts, activity records, pending automation states and Instagram connections, and the corresponding marketing-email contact is removed. Each deletion is recorded in an audit log.
• Contact deletion: Individual contacts (collected email addresses) can be deleted by the customer, supporting erasure requests from data subjects.
• Automatic expiry: Temporary records used while an automation waits for a user action (for example an email reply or a follow) stop being usable within 24 to 48 hours depending on the automation type and are physically deleted from the database within 48 hours.
• Logs: Application and access logs are retained for 30 days.
• Snapshots: See Section 8. Snapshots are restored only to recover the service from a system failure. Personal data that had been deleted before such a restore would have to be deleted again afterwards; there is no automated reconciliation for this, so we re-run deletions manually on request.

13. Review of these Measures