Technical and Organisational Measures

These are the technical and organisational measures Swat.io GmbH applies to thestory.run under Art. 32 GDPR. The Data Processing Agreement references this page, so that improvements take effect when they are made. The measures are not reduced below the level summarised in clause 3.2 of that agreement.

This page covers thestory.run. Other Swat.io products run on separate infrastructure and have their own measures.

1. Pseudonymisation and encryption

In transit. All traffic is encrypted with TLS, including the connection between the application and its database, which is authenticated against the provider’s certificate authority.

At rest. All stored data is encrypted at rest by the underlying managed services: the managed database encrypts stored data automatically, and object storage uses AES-256 server-side encryption.

Credentials held on a customer’s behalf carry a second, application-level layer: AES-256-GCM under versioned keys that support rotation without downtime, with each value bound to the record it belongs to. This covers a member’s social network access tokens, an organisation’s Slack token, and an organisation’s own AI provider key.

Authentication secrets are never stored. Session tokens, sign-in tokens, authorisation codes and API keys are held only as cryptographic hashes.

Pseudonymisation. Product analytics records actions, never content. The marketing site’s analytics are cookieless and store no IP address.

2. Physical access control

The product runs entirely on managed cloud infrastructure in the Frankfurt region of the European Union. Swat.io operates no data centre or server hardware of its own for this product; physical access control is the infrastructure provider’s, under its own certifications and audit reports. The provider is named in the Annex to the Data Processing Agreement.

Object storage is in the same region and is not publicly accessible.

3. System access control

For users. Sign-in is passwordless: a single-use, time-limited, rate-limited link. There is no password to reuse or leak. Sessions use httpOnly cookies with SameSite set. Every member can review their own active sessions and end any they do not recognise. Organisations can require sign-in through their own identity provider via SAML.

For Swat.io. Administrative access to the cloud account requires multi-factor authentication. Deployments authenticate to the cloud provider with short-lived federated credentials rather than stored keys. A deployment proceeds only after the full automated security and test gate has passed.

4. Data access control

Within the product, access is determined by a member’s role in their organisation. Unfinished drafts are never visible to colleagues, and this is enforced at the data layer rather than in the interface. Coach conversations are visible only to the member who had them.

Internal access to customer content is restricted to a limited number of named personnel, for operating and supporting the service, and is protected by multi-factor authentication.

5. Separation control

Every record belongs to an organisation and every query is scoped to it. This is covered by a dedicated isolation test suite that runs on every change against a real database and fails the build if any cross-tenant access succeeds.

Credential encryption reinforces the same boundary: each encrypted value is bound to the organisation or member it belongs to.

Development, test and production are separate environments with separate data. Production data is not copied into development.

6. Input control

Mutating actions within an organisation are recorded in an append-only audit log: publications, campaign changes, membership changes. The append-only property is enforced at the database level.

Administrators can read the audit log for their own organisation.

7. Availability and resilience

The application runs on a managed container service with health checks and automatic rollback if a release fails to start. Database and object storage are managed services in the same region.

Database recovery has two layers:

• Point-in-time recovery in 5-minute increments across the previous 7 days.
• Weekly snapshots, of which the six most recent are retained, reaching back at least 30 days once the set has filled.

Both are verified automatically every week.

Restoration is tested and maintained. Backups are created and verified automatically, and restoration follows a documented procedure that is tested and kept current. Service is restored within one business day at the latest.

Schema migrations are applied automatically at release and are exercised against populated data before reaching production.

8. Regular testing

Every change passes an automated gate before it can be released. The gate blocks the release and covers:

• dependency vulnerability auditing, failing on high and critical advisories;
• secret scanning across the working tree and the full repository history;
• the complete test suite, including tenant isolation, against a real database;
• static analysis and accessibility checks at zero warnings;
• Content-Security-Policy verification of the built output;
• a container image build.

Dependencies are updated on an automated weekly schedule across application packages, build actions and the container base image.

Internal security reviews of the architecture and deployed infrastructure are carried out and documented, with findings tracked to closure.

9. Sub-processor management

Sub-processors are named in the Annex to the Data Processing Agreement, with their location and, where established outside the EEA, the basis for the transfer. Each is engaged under an agreement meeting Art. 28(4) GDPR that imposes equivalent obligations.

Customers are informed of an intended change of sub-processor in advance and may object within 30 working days.

10. Confidentiality and training

Everyone authorised to process personal data is bound to confidentiality, and the obligation survives the end of their engagement. Personnel are instructed on the resulting duties. These obligations form part of the employment relationship with Swat.io GmbH.

11. Deletion

On termination. Personal data is retained for 30 days after the agreement ends so that it can be exported, and deleted thereafter. Immediate deletion can be requested at any time. Statutory retention obligations, in particular accounting records, are unaffected.

On user action. Disconnecting a social network account deletes the stored tokens and identifiers immediately. Deleting a piece deletes it. Removing a member from an organisation deletes the files stored for them.

Continuously. An automated housekeeping process removes expired sign-in tokens, expired sessions, spent authorisation codes, rate-limiting counters and transient integration state. Rate-limiting counters, the only place an unauthenticated visitor’s IP address is held, are removed within 24 hours.

In backups. Deleted data ages out of the recovery layers in section 7. A disaster-recovery restore reproduces the data as it stood, so deletion requests are applied to the live system and reapplied after any restore.

12. Incident response

Where a personal data breach affects a customer’s data, Swat.io notifies that customer without undue delay, with the information they require for their own obligations under Art. 33 GDPR, and supports them in meeting them. The customer is the controller and makes the notification to the supervisory authority. This obligation is contractual, in clause 3.5 of the Data Processing Agreement.

To report a suspected vulnerability or incident: lab@swat.io.

Changes

These measures are kept current; the date at the top is the most recent revision. Because they are published here rather than fixed into the Data Processing Agreement, an improvement takes effect when it is made, and the measures are not reduced below the level summarised in clause 3.2 of that agreement.

Questions: lab@swat.io.