Data Security and Integrity

Last updated: 2 October 2026

Security and integrity are built into how slideAcross works. They aren't added afterwards. This page explains the measures in place across slideAcross and dataLayers. Our Privacy Policy covers what personal data we collect and why. Our Terms and Conditions set out our commitments when we process data for your organisation.

1. Hosting and encryption

• UK hosting: the app, databases and files are hosted on Amazon Web Services infrastructure in London. Emails are sent through Amazon's UK email service.
• Encrypted in transit: every connection to slideAcross uses HTTPS (TLS). Plain web addresses are redirected to secure ones. Connections to our suppliers, including the AI services, Google, Microsoft and Stripe, are encrypted too.
• Encrypted at rest: the server storage that holds the app, its databases and files is encrypted at rest by Amazon Web Services.
• Separate development and testing: new features are built and tested on a separate, access-protected environment with its own database, sign-in cookies and test payment system.

2. Accounts and sign-in

• Passwords are stored only as a one-way, salted hash. Nobody at slideAcross can see them.
• Brute-force protection: repeated failed sign-ins and password reset requests are limited, both per account and per network address.
• Password resets use one-time links that expire after an hour. Opening a link doesn't use it up, so email security scanners can't spoil it. Reset requests never reveal whether an email address has an account.
• Sessions are renewed every time you sign in, and every security token we issue is generated with a cryptographically secure random number generator.
• Account changes: changing your email address needs your current password, and we email a notice to your old address. We also email you when a new sign-in method is added to your account.
• Sign in with Google, Apple or LinkedIn: we only link a provider when it has verified your email address and the address exactly matches your slideAcross account.

3. Access control

• Separate organisations: each organisation's presentations, libraries and data are kept apart. Every request is checked on our servers against the person making it. We never rely on what the browser says.
• Roles: owners, admins, editors and viewer/commenters each have clearly defined rights. Organisations can be divided into departments and teams, and content can be made available to one department or to everyone.
• Presentation permissions: access to each presentation is granted to named people or groups, as an editor or as a viewer/commenter.
• Share links use long random tokens and expire.
• Leavers and licences: admins can remove a member straight away. A member who loses their licence is suspended and can't open the organisation's presentations until they're reinstated.

4. Data permissions

dataLayers lets everyone see the headline story while controlling who can dig deeper. For each dataset, rules can give a department:

• Rules are enforced on our servers for every drill-down, filter, suggestion and new data slide. They aren't just hidden in the page.
• Teams follow their parent department's rule unless they have their own. Once a dataset has any rules, departments without one are locked out until they are set up.
• Only the organisation owner and the person who brought the data in can manage the rules. Organisation admins don't get access to all data automatically.
• People viewing through a share link can't explore data that has rules.

5. Connected data sources

• Only what you choose: for Google Sheets, slideAcross can only open the files you pick in Google's own file picker. The rest of your Google Drive stays invisible to us. Microsoft OneDrive and SharePoint connections use read-only permissions. We only ever read, and never change or delete anything in your accounts.
• Personal: a connected account always belongs to the person who connected it, never to an organisation. Each person's connections are used only for sources they set up.
• Long-lived tokens stay on our servers: the tokens that keep an account connected are stored server-side and never sent to the browser. Google's file picker gets a short-lived token, valid for an hour at most and limited to files you choose, only while you're picking. Microsoft tokens are rotated on every refresh.
• Disconnect any time: disconnecting deletes the stored tokens and, for Google, revokes our access with Google straight away.
• Files from web addresses are only fetched from public internet addresses over standard web ports, with size limits and checks on each redirect. This stops the feature being used to reach private networks.
• Only what's new: each refresh stores only the new rows. If the same sheet is connected twice in an organisation, it's read once and shared.

6. AI and your data

• Your choice of supplier: organisations choose between OpenAI and Google Gemini for text, images and data, and can switch at any time.
• Not used for training: we use paid business access to these services. Under their terms, your content isn't used to train their models.
• Only what's needed: we send only the content needed for the task, such as your prompt, the relevant slide or library extracts, or a summary of chart data. Your whole account is never sent.
• No-AI option for data: dataLayers can write chart summaries with its own built-in language engine. It gives the same words for the same numbers every time, and nothing leaves our servers.
• Grounded in your content: slides created mid-presentation are built from the documents and data in your own content libraries.

7. Application security

• Uploads are checked by content, not by file name. Files are saved under long random names with size limits, and videos are inspected before they're accepted. The folders that hold uploads can't run code, and their contents can't be listed.
• Original documents stay private: the documents and spreadsheets a content library was made from can only be downloaded by people who are allowed to see that library. Images used on slides are served by their unguessable addresses, so a shared presentation shows correctly wherever it's opened.
• Protection against harmful content: text from users and from servers is escaped before it's displayed. Slide content is checked against an allow-list of safe elements when it's saved.
• Secrets kept out of code: passwords and API keys for our suppliers are stored outside the website, in protected configuration.
• Verified payment messages: messages from Stripe are checked for a valid signature before we act on them.
• Trusted libraries: third-party code libraries are pinned to fixed versions, and integrity checks are used where they're available.
• Regular reviews: we review our code for security problems, and fix issues in order of risk.

8. Backups and integrity

We use several layers of protection, so that work can be recovered and data stays correct:

• Restore points while you edit: a restore point is saved up to every five minutes while a presentation is being changed. Each one records every slide's content, order and layer, so a restore puts the slides back exactly as they were.
• Full database backups four times a day.
• Daily server mirroring for resilience.
• All-or-nothing changes: multi-step operations, such as restoring a presentation or deleting an account, run as single transactions. A failure part-way can't leave things half done.
• Data history: each refresh of a connected source is kept as a separate capture. Earlier figures are never overwritten, and reports can compare periods reliably.
• Present offline: once a presentation is open, it keeps working without an internet connection. AI, data refreshes and sharing need to be online.

9. Reliability

• Heavy jobs, such as reading large spreadsheets, are queued and limited, so one large task can't slow everyone else down.
• Scheduled refreshes run inside the hour window you choose, and are retried automatically after a temporary error.
• If a data source fails, the reason is recorded and shown, and it's tried again later. Other sources carry on.

10. Payments

Payments are handled by Stripe, a PCI DSS Level 1 certified payment provider. Card details are entered directly with Stripe and never pass through or get stored on our servers.

11. Your controls

12. Incidents and reporting

If a security incident affects your data, we will act quickly to contain it. We'll tell affected customers without undue delay, and notify the Information Commissioner's Office where the law requires it.

If you think you've found a security weakness, please tell us through our contact form and don't publish it until we've had a chance to fix it. Please don't access other people's data, or disrupt the service, while testing. We're grateful for responsible reports.