Security and data handling

Courtesy translation. This is an English translation of a document originally written in Italian, provided to make it readable. The Italian version is the binding one: in case of any discrepancy between the two texts, the Italian text prevails.

This page gathers the technical and organisational measures Social Web Automation protects client data with. It is written for someone assessing a supplier before signing: it says what we do and, where we do not do something, it says so instead of talking around it.

1. Transport and headers

• HTTPS across the whole site, with Strict-Transport-Security set to two years, extended to subdomains and with preload.
• A restrictive Content-Security-Policy: scripts may come only from our own domain; object-src disabled and base-uri locked.
• frame-ancestors: none and X-Frame-Options: DENY: the site cannot be embedded in someone else’s iframe, so clickjacking is not practicable.
• X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: camera, microphone and geolocation disabled at document level.

2. Access and accounts

• Passwords stored with bcrypt, never in clear text and never reversible.
• Multi-tenant isolation: every request is bound to the client that originated it; one client’s data is not reachable from another.
• Rate limiting on login, registration, password change and on the interfaces that generate content.
• Dashboard access is restricted to approved accounts; credentials are the responsibility of whoever holds them.

3. Payments

Payments go through hosted Stripe Checkout: the page where the card is entered belongs to Stripe, on Stripe’s domain. No card data passes through, is processed by, or is stored on our systems, and there is no card field anywhere in our code. For PCI-DSS this places the activity in the SAQ-A scope, the lightest the standard provides.

4. Where the data lives and who processes it

The full list of external processors, with the activity performed and the legal basis for every transfer outside the European Union, is in the Privacy Policy under point 5. It is a named list, not one by category: suppliers are identified one by one. Transfers outside the EU rely on Standard Contractual Clauses and/or Data Privacy Framework adherence.

5. Artificial intelligence

• Uploaded material is used only to generate the content requested.
• We do not train models on client data, and we select suppliers that offer contractual guarantees to that effect.
• Nothing is published without human approval. The detail is in the AI transparency notice.

6. In case of a breach

The procedure is written before it is needed: detection and containment, risk assessment, notification to the supervisory authority within 72 hours under art. 33 GDPR, communication to data subjects without undue delay where the risk is high, and an entry in the breach register even when notification is not required. The full text is under point 9 of the Privacy Policy.

7. Reporting a vulnerability

If you find a security problem, write to swsdautomation@gmail.com with the subject “Security”, describing how to reproduce it. We reply within five working days. We ask you not to disclose the problem until it has been closed, and not to access data that is not your own.

8. What we do not claim

In fairness to anyone assessing us: we are not SOC 2 or ISO 27001 certified, we do not publish a status page and we do not offer a contractual availability SLA. These are choices consistent with the size of the business, not omissions. If your supplier selection process requires one of them, say so first: better to know at the start than halfway through a project.

A data processing agreement (DPA, art. 28 GDPR) is prepared on request for clients who need one.

9. Updates

This page is reviewed whenever the measures described change. Last revision: 8 September 2026.