Provider Access Policy

Version 2026-10-20.1, updated 20 October 2026. Governing law: England and Wales.

1. Who this applies to

This policy is published by Lewis Plume trading as SwimNexus ("SwimNexus"). It covers access by SwimNexus personnel, and anyone acting for SwimNexus, to a customer organisation's accounts and information in the SwimNexus platform and its products. SwimNexus is currently run by one person. If anyone else is ever given platform administrator access, this policy applies to them in the same way.

2. When access may be needed

SwimNexus may need to access a customer organisation for these purposes only:

• customer support that the club has asked for;
• technical troubleshooting of a problem the club has reported;
• investigating a reported defect that cannot be reproduced without seeing the club's configuration;
• data recovery that the club has asked for;
• a security investigation;
• maintenance that cannot be done without access to the club's workspace;
• responding to an incident affecting the service or the club's information; and
• meeting a legal obligation.

Access is not used for browsing, sales, marketing, analytics, product research or training of artificial-intelligence models.

3. Who can authorise access

• Routine access is authorised by an owner or administrator of the club, in SwimNexus, under Support access. The club can authorise a session when it asks for help, or approve a request that SwimNexus makes. SwimNexus cannot approve its own request.
• Emergency access is authorised by SwimNexus alone, because the situation does not allow time to wait, and is subject to the safeguards in section 6.
• Demonstration tenants that hold only fictional data are opened by SwimNexus without club approval. They are still recorded.
• A person who is genuinely an owner or administrator of a club (for example a club volunteer who also works for SwimNexus) uses their ordinary club account for club work. That is club access, not provider access.

4. Routine access: how it works

• A request states the reason, the category, the scope and the longest the session may last. Reasons must be specific; "maintenance" alone is not enough.
• The club's approval is for one session. It must be used within 72 hours or it lapses. The session lasts no longer than the approved length (at most 8 hours) and then ends automatically.
• The club can reject a request, and can revoke an approval at any time. Revocation ends an open session on its next page request.
• SwimNexus does not use a club user's password. Access is through a separate, short-lived, single-use launch that creates a clearly named SwimNexus support identity inside the club workspace.

5. What can be seen and done

Even within a scope, SwimNexus looks at only what the task needs. Where a problem can be solved by a screenshot or description from the club, we ask for that first and avoid opening the account.

6. Emergency (break-glass) access

Emergency access may be used only to protect the security of the service or the integrity of data: for example a suspected account compromise, active abuse of the platform, or corruption that is spreading. It is not used because a request is urgent for convenience.

• The SwimNexus administrator must write a justification of at least 40 characters, choose a security, incident, data-recovery or urgent maintenance category, and re-enter their own SwimNexus password to verify their identity.
• Access lasts at most 2 hours, is read-only unless changes are essential, and excludes member, welfare and finance screens.
• The session is flagged as an emergency in the evidence record and is marked for review.
• The club's owners and administrators are told by email that emergency access was used, unless doing so would be unlawful or unsafe, for example because the person to be told is the subject of a security investigation. In that case the reason for withholding notice is recorded.
• Within 7 days SwimNexus reviews the session against its justification and records the outcome. Repeated failed identity checks lock emergency access for 15 minutes.

7. How access is restricted

• Access is checked on the server for every request. A session is valid only for one organisation and one tenant identity; it cannot open another club.
• The session scope controls which administration features the support identity holds. Features are removed when the session ends.
• Read-only sessions refuse every request that would save a change.
• If the record of the session cannot be written, access is refused.
• For SwimClubOS, platform administrator status on its own does not open a club's workspace.

8. What is recorded

For each session SwimNexus records, in Coordinated Universal Time (UTC): the SwimNexus person, the organisation, the reason and category, the authorisation reference, the start and end times, the scope, whether it was an emergency, a session identifier, and each page opened or change attempted (the address of the page, never form contents). Records do not contain passwords, medical or welfare details, session tokens or private document content.

Records are append-only and chained so that edits or removals can be detected. They are kept for at least 24 months. Where SwimNexus changes something on a club's behalf, the change is attributed to the SwimNexus support identity and is therefore distinguishable from the club's own users. Each club can see the history for its own account in SwimNexus under Support access: when, why, what scope, how much activity, whether it was an emergency, and whether it has been reviewed.

9. How access ends

A session ends when the SwimNexus administrator ends it, when its time runs out, when the club revokes it, when a newer session replaces it, or when the organisation is closed. Ending a session switches off the support identity's permissions.

10. Confidentiality

Anyone at SwimNexus who sees club information in a session must keep it confidential, use it only for the stated purpose, and not copy it elsewhere except where needed to fix the problem. Club information is not put into public tickets, source control, or unapproved third-party tools, including artificial-intelligence tools.

11. Data protection

When SwimNexus handles a club's operational records in a session it acts as the club's processor under the Data Processing Agreement and follows the club's documented instructions. Access under this policy is one of those instructions. SwimNexus is an independent controller only for its own account, contract, support, security and business records. The data ownership explanation sets out the roles.

12. What this policy does not do

• SwimNexus runs its own servers and databases. The person who administers the servers can technically reach any club database directly, outside the application. The session recording above does not capture that kind of access. It is limited by the commitments in this policy, by the confidentiality duty, and by the fact that the recorded support session is the normal route. Direct server access is used only for operating, maintaining, backing up and restoring the service, and for the purposes in section 2.
• SwimMeetOS is not gated in the same way yet. A SwimNexus platform administrator can currently open a meet host's organisation workspace without the host approving each session. Each such entry is recorded in the same evidence trail, but it is not blocked. Closing this gap is planned.
• Multi-factor authentication is not currently enforced on SwimNexus platform accounts. The emergency identity check is a password re-entry, not a second factor.
• This policy is not a certification and has not been independently audited.

13. Legal requests

If a court, regulator or law-enforcement body lawfully requires SwimNexus to disclose club information, SwimNexus will disclose only what is required, will tell the club unless the law prevents it, and will record the request.

14. Questions and changes

Email [email protected] about this policy. A material change to this policy is published as a new version and, where it changes obligations under a signed agreement, is put to the club through the agreement re-acceptance process.