How we handle your information.
What we collect through this website and the client portal, why we use it, who else handles it and the rights you have.
Who we are
1ST Cyber provides penetration testing. This notice explains how we handle personal information collected through this website and the 1ST Cyber client portal. We decide how that information is used, which makes us its controller under UK data protection law.
- Registered name
- 1ST CYBER LTD
- Company number
- 17492640
- Registered in
- England and Wales
- Registered office
- Icon Office, 182-184 High Street North, London, England, E6 2JA
- ICO registration
- ZC270122
- Privacy contact
- privacy@1stcyber.co.uk
What we collect and why
Enquiries
When you send an enquiry through our contact form, we receive your name, work email address, organisation, the service you choose, if any, and the message you write. We use them to reply to you and to discuss the testing you need. Someone in your organisation who may authorise testing can also ask us, in the client portal, to add a colleague: we then receive the colleague’s name, work email address and, if given, job title, with the name of the person who asked, and keep them as an enquiry so that an administrator can add the colleague. With each enquiry we record when it arrived, whether we have replied to it, invited you to the client portal from it or closed it, which administrator handled it and when they replied, and the organisation, account and request it became. Enquiries are read by 1ST Cyber administrators in the client portal, who can delete them. Deleting an enquiry that became an account deletes the enquiry only: the account, and any organisation and draft request made from it, keep the details and message copied into them, and are deleted separately.
Client portal accounts
When you create an account, we store your name, work email address and organisation name, and a one-way hash of your password. We never store the password itself. We use these details to sign you in, to show you your organisation’s engagements and to let you know when one of them is updated. We also record when you last signed in and the time before that, counting the visit on which you created your account or first set its password: the portal uses them to show you what has happened since your last visit, and 1ST Cyber’s administrators see when a client last signed in beside anything they are waiting for that client to do, and in their list of accounts. We record the job title you give when you authorise testing, so it can be offered again next time. An administrator at 1ST Cyber can add a colleague to your organisation’s account, with their name, work email address and, if given, job title. An administrator can also make an account from your enquiry: an organisation for you, your account, with your name, the work email address your enquiry came from and, if given, job title, and a draft request filled from your enquiry, for you to check before you submit it. As your organisation’s first user, you may authorise testing for it, as whoever registers an organisation may. We record who in your organisation may authorise testing, which authoriser asked for someone to be allowed to, which administrator allowed it and when. To set or reset a password, an administrator issues a link that works once, within 24 hours; we store only a one-way hash of it, who issued it, whether it was emailed or shown, and when it was used. When email is set up, the link goes only to the account’s own email address; otherwise it is shown once to the administrator, who passes it on, and anything that account authorises is flagged for our quality review until it sets a password from a link sent to its own email address. Using a link or changing your password signs you out of your other sessions. Accounts for our own staff hold the same details and are created by a 1ST Cyber administrator.
Your organisation’s profile
Your organisation’s profile holds its telephone number, a primary and a technical contact (a name, work email address and telephone number), emergency contacts for testing hours (a name, a telephone number and when they can be reached), the assets or techniques you exclude as standard, your preferred testing hours and notes for testing teams. Everyone in your organisation with a client portal account can see and change it, and 1ST Cyber administrators can see it. We record each change, with the old and new values, who made it and when. We use it to fill in new requests: the request form’s contact comes from its primary contact (when it has a name and an email address), the contact telephone number from that contact or otherwise from your organisation’s telephone number, and its exclusions, hours and notes fill the form too, for you to check before you save it. Its emergency contacts with a name, telephone number and hours are added to each new request; the form says so once it has read the profile. The technical contact is not copied into requests: 1ST Cyber administrators and the penetration testers assigned to one of your engagements can see it as it stands, the testers in that engagement’s testing brief. The Organisation page also lists your organisation’s document library: the supporting documents and pre-test information we accepted on your engagements, with when each was accepted and any expiry date. Everyone in your organisation with a client portal account can see it.
Engagements
When you request a penetration test, we store the scope you give us: your organisation’s name, a contact name, email address and telephone number, the assets to test with who hosts each one, and details such as the environment, objectives, exclusions, when testing may take place and any testing rules you set, and, for an asset a third party hosts, their permission: the document you upload, or your confirmation that you hold it, with your name and when it expires. We also store the emergency contacts you give us for testing hours (a name, a telephone number and when they can be reached), the scoping documents and other files you upload, messages in the Discussion tab and on a request or a finding (each with the request or finding it is about), and the findings, evidence, retest results and reports we add. We record who agreed and who authorised each version of the scope, and when, with the job title given at authorisation, the testing rules in force at the time and the emergency contacts given for testing hours; this record of each authorisation is kept with the engagement, and who authorised it, their job title and when are printed in its report. When a change to the scope is proposed while testing is booked or under way, we record who proposed it and when, who agreed it, and, if it is declined, who declined it, when and the reason given. We record the testing dates, daily hours and lead tester we book, when each tester confirmed they had read the version you authorised, and when the testing window ended while testing was under way. When contact details, emergency contacts, preferred dates and hours, notes for the testing team or the engagement’s title are changed, we record the old and new values and who made the change. When you start a request from the information of an earlier engagement, we record which engagement and scope version it came from. When you use a document from the library on a new request, we store a copy of it with that engagement, check the copy for malware again before anyone can download it, and record which document it was copied from. If you ask us to stop testing, in the portal or by phone, email or in person, we record who asked, how, when and the reason given, which member of our staff recorded a stop that reached us outside the portal, and each tester’s confirmation that they stopped. When we ask you for something further, such as a document or an answer, we record what we asked for, why, what follows if you can’t provide it and when it is due; who provided it and when, with the answer or the files; who accepted or returned it and when, with the reason given for a return; and who marked it not available or not needed, when and why. We also record what holds back testing: a blocker raised, or an engagement put on hold, with what it is about, who is to clear it, and who raised and cleared it and when (a note we add for our own staff is never shown to you); and when the client portal finds that a hosting provider’s permission you gave us has expired, or that 1ST Cyber’s testing source addresses have changed since you authorised, when it found it, and who acknowledged the new addresses and when. We keep records of when test access was provided, verified and revoked, never the credentials themselves, and we record that 1ST Cyber has deleted its copies of them when the engagement is complete. While testing is under way, we record how far each asset in scope has been tested, who recorded it and when, and why an asset could not be tested; you are shown how many assets are at each point, and the report says how many were tested. Our testers may post dated notes on their progress, which you can read. If we phone your emergency contact about an urgent matter during testing, we record who we called, when and why, with a note of what was said for our own staff; you are shown who we called and when. If a finding is on something outside the scope you authorised, we record why it was recorded there and our delivery lead’s decision on it, including whether and when you were told. For each finding we record when the issue was observed and, for each piece of evidence, when it was obtained, and, when a member of our staff checks a finding in quality review before it is published, who checked it and when; a draft finding we withdraw before publication is kept for our records and is never shown to you. When we test for your organisation again, the testers may mark each earlier finding they look at as still present, checked and fixed, or not checked this time, with how they checked it or why not; we record who marked it and when, and who checked the mark in quality review. You see a mark once the later engagement’s report is published, and a mark never changes the earlier finding’s status. If your organisation uploads evidence that a published finding has been fixed, we store it with that finding and check it for malware like every file; people in your organisation who have a client portal account, the penetration testers assigned to the engagement and 1ST Cyber administrators can see it, and it is never part of what you authorise. Pre-test information that you or we upload to prepare for testing, such as a network diagram, an API specification or a connection guide, is stored with the engagement and checked for malware like every file; JSON, YAML, CSV and text files are also checked for passwords, keys and tokens, and refused if they hold one. The same people can see it, and it is never part of what you authorise. If a published finding is changed later, such as its severity, we record what changed, its old and new values, why, who proposed and who approved the change, and when; you are shown the change and why it was made in the portal and in a report update, and the report you were given is kept as it was published. When your organisation requests a retest, we record who requested it and who confirmed it, with their job title and the sentence they confirmed, what changed, the dates the retest may take place, whether test access is still available, and a copy of your emergency contacts and our source addresses at that time. If your organisation accepts the risk of a published finding, we record who asked, who approved it, their job title, when, and whether the approval was given in a session begun from a link our administrators issued, the reason, any compensating controls, the review date, and our acknowledgement or the reason we declined it; people in your organisation with a client portal account, the assigned testers and 1ST Cyber administrators can see it, except our staff’s own note on it and how the session began, which only our staff see. If your organisation disputes a published finding, we record who disputed it, when and why, the evidence uploaded with it, and the outcome we record with its reason, and who recorded it; the same people can see it, except a note our staff keep when one of them decides a dispute on a finding they wrote, which only our staff see. For a published finding that needs action, your organisation can name an owner, one of its people with a client portal account, and a target date; we record who set them and when, and the people who can see the finding can see them. When a finding’s remediation status is changed, we record who changed it and when, with any note given, which is posted on the finding’s thread; a change made by our staff always has a note and is shown as changed by 1ST Cyber. We use all of this to plan, carry out and report on the testing you authorise.
If a message or file is posted by mistake, for example one that contains a password or other credential, tell us and a 1ST Cyber administrator will remove it. Its content is deleted from the client portal, and from our backups as they expire; a note stays in its place saying who removed it, when and why, and the engagement’s history records the same, never the content. Removing a file also removes each copy of it made from the document library, except a copy that is part of an authorisation’s record, which stays. Reports, the record of each authorisation and the documents it covered are never removed this way: a report is checked before we publish it, and one that is wrong is withdrawn or made again first.
Engagement information can be seen by people in your organisation who have a client portal account, by the penetration testers assigned to the engagement and by 1ST Cyber administrators. Your organisation sees findings, evidence and reports once the report has been reviewed and published, on each engagement and in the organisation’s findings history, which lists the published findings of all its engagements and which 1ST Cyber administrators can also see. When we test for your organisation again, the testers assigned to the new engagement can also see the published findings of your earlier engagements on assets within the new engagement’s authorised scope: those still open or accepted, to check whether they have been fixed, and those resolved, to record an issue that has come back.
When we test your systems, or read documents and evidence that contain other people’s personal information, we act on your organisation’s behalf, as its processor, under the terms of our engagement agreement. Your organisation remains the controller of that information. This notice covers the personal information we hold as controller: about you as our contact, and about the people who use the client portal.
Security records
The client portal keeps an audit trail of actions such as creating an account, adding a colleague, signing in, issuing a set-password link, setting or changing a password, asking for or allowing someone to authorise testing, asking for a colleague’s account, changing the organisation’s profile, revising or authorising a scope, asking for a further item and providing, accepting, returning or settling it, booking or stopping testing, changing the testing team, uploading, downloading or withdrawing a file, removing a message or file posted by mistake, and publishing a report. Each entry records the account that acted and when. Failed sign-in attempts are recorded without the account.
Each entry about an engagement is marked either as one your organisation is shown or as one for 1ST Cyber staff only, and anything not named as your organisation’s is for staff only. The entries your organisation is shown make up the engagement’s history, which everyone in your organisation with a client portal account can read in the engagement’s Discussion tab and on its Overview, with when each thing happened and, for most, who did it. Internal notes, draft findings, downloads and the other staff-only entries are never shown to you.
We also use the dates and times in these records to measure, in aggregate, how long each stage of our service takes, so that we can improve it. The measures are medians and other summary figures, never a measure of any one person’s work, and only 1ST Cyber administrators see them; they can see which engagements a figure comes from.
To slow down repeated attempts to sign in, set a password from a link, create accounts or send enquiries, we keep short-lived counters under a one-way hash of your IP address and, when you sign in, of the email address you entered. Each counter runs for 15 minutes or an hour, and expired counters are deleted the next time someone signs in or creates an account. Signed-in accounts also have counters on uploads, report generation and other actions such as changing a password, asking an authoriser, changing the organisation’s profile or asking for a colleague’s account, kept the same way under a hash of the account’s identifier.
Our hosting provider records technical logs of requests and errors, which can include your IP address.
Notifications
When an engagement is updated, the client portal records a notification for the people who need to act on it or to know of it. If email notifications are switched on, we also email them to say whether there is an update or something for them to do, with a link to sign in; the email does not say what the update is. For each notification we record whether its email was sent, failed or was not sent, and why: email is switched off, the account is a demonstration one, or the same kind of update on the same engagement was emailed to the same person in the previous 15 minutes (a request for a further item, or one returned to you, is never held back this way). An email that fails is tried again, no more than three times in all, when a member of our staff next signs in or opens their overview within a day of the update, or, for an alert that testing must stop, for as long as a tester has yet to confirm that they stopped, for an alert that the testing window ended, for as long as testing is still under way past it, for an alert that a hosting provider’s permission has expired, for as long as testing is held back on that asset, and for an alert that 1ST Cyber’s testing source addresses have changed, until they are acknowledged. These records are never shown in the portal: our administrators see only how many emails failed in the last seven days. Administrators are emailed in the same way when a new enquiry arrives. When someone is added to your organisation’s account or allowed to authorise testing, your organisation’s authorisers are emailed to say there is an update to its people, and administrators are emailed when an authoriser asks for a colleague to be allowed to authorise or for a colleague’s account. Like the enquiry email, these emails are sent once, only when email notifications are switched on, and no notification is recorded for them. A set-password email carries only its link. These emails never include engagement details, findings or the content of an enquiry.
Feedback
When an engagement is complete, we may ask you one optional question about how satisfied you were, with space for a comment. We record your answer, who gave it and when, and use it only to improve our service. Our testers and other staff see only that feedback was received. 1ST Cyber administrators see scores and comments only as totals for a period with at least three responses, without the engagement or your name.
Our lawful bases
We rely on these lawful bases under the UK GDPR.
Enquiries, client portal accounts, your organisation’s profile, engagements, findings, reports and messages: our legitimate interests in answering enquiries and in agreeing, carrying out and reporting on the testing your organisation asks for. Where you contract with us yourself, as a sole trader for example, the basis is that the processing is necessary for our contract with you or for steps you ask us to take before entering one.
The record of each authorisation, and the records of who asked us to stop testing and when: our legitimate interests in being able to show that every test was authorised, and stopped when asked, including if a claim is made against either of us.
Security records, counters on repeated attempts and hosting logs: our legitimate interests in keeping the website and the client portal secure and available.
Notification emails: our legitimate interests in telling you when an engagement needs your attention.
Measuring, in aggregate, how long each stage of our service takes, and any feedback you choose to give: our legitimate interests in improving our service.
Keeping accounting and tax records, such as invoices to your organisation that name you as its contact: our legal obligations.
Where we rely on legitimate interests, we have weighed them against your interests and rights, and you can ask us for that assessment.
You have the right to object to any processing based on our legitimate interests. To do so, use the contact details in “Your rights”.
The session cookie described below is strictly necessary for the client portal to work, so it does not need your consent.
Who else handles it
- Amazon Web Services hosts this website and the client portal, in London, and stores the database and the files you upload.
- A malware-scanning service checks every file uploaded to the client portal before anyone can download it. It is Amazon GuardDuty Malware Protection, run by Amazon Web Services in London.
- Amazon Web Services also sends the notification emails and set-password links, from London, when email is switched on. It receives each recipient’s email address and the short message described above, or, for a set-password email, the one-time link.
We don’t sell personal information or share it for advertising.
We store your personal information in the UK, with Amazon Web Services in London, which also sends our emails from there.
Some processing takes place outside the UK. Requests to this website are handled by Amazon Web Services’ delivery network (CloudFront) at the location nearest you, which may be outside the UK; it handles your IP address and the request in transit, and keeps copies only of the website’s own files. The network’s settings, its firewall rules and its performance figures are held in the United States.
Where personal information goes to the United States, it is protected by the UK–US data bridge (the UK Extension to the EU–US Data Privacy Framework) where the supplier is certified under it, and otherwise by the UK International Data Transfer Addendum to the EU standard contractual clauses in the supplier’s data processing terms. You can ask us for a copy of the relevant safeguards.
How long we keep it
We keep personal information only as long as we need it.
Enquiries that don’t lead to an engagement: 12 months after our last contact with you.
Client portal accounts, and the records of set-password links: while your organisation is a client, and for 12 months after the account is deactivated or your organisation’s last engagement is complete, whichever is later. Records of who did what in an engagement keep the person’s name after that.
Your organisation’s profile, and its record of changes: while your organisation is a client, and for 12 months after its last engagement is complete.
Engagements: the scope and each version of it, the record of each authorisation and the documents it covered, stop requests and their confirmations, requests for further items and their answers, records of when test access was provided, verified and revoked, messages, findings and their owners and target dates, changes to published findings and report updates with their change logs, testers’ marks on earlier findings, retest requests and results, risk acceptances, disputes and reports: 6 years after the engagement is complete or withdrawn. This is the usual period in which a claim about the work can be brought.
Engagements withdrawn before any testing was authorised: 12 months after they were withdrawn.
The documents an authorisation covered: 6 years, with the record of that authorisation.
Other uploaded files and evidence (pre-test information, evidence in findings and evidence of a fix): 12 months after the engagement is complete, so that retests can use them, then deleted. The published report and its findings are kept for the 6 years above.
Your organisation’s library of reusable details: while your organisation is a client, and for 12 months after its last engagement is complete. Copies made into a request are kept with that engagement.
Accounting and tax records: 6 years after the end of the financial year they relate to.
Credentials and access details you give us for testing: never stored in the client portal. Our testers delete their copies when the engagement is complete, and we record that they did.
Personal information we come across on your systems during testing: handled as the rules recorded with each authorisation say. Testers delete their working copies within 30 days of the report being published.
The security audit trail: entries about an engagement are kept with the engagement. Sign-in records and other entries about an account are kept for 2 years.
Notification records and whether each email was sent: 12 months.
Feedback: 2 years after it is given. Totals that identify no one may be kept longer.
Counters on repeated attempts: they expire after 15 minutes or an hour, and are then deleted. Session cookies: up to 8 hours, or until you sign out.
Hosting logs: 90 days. Records of access to stored files (our cloud provider’s audit log): 1 year.
Backups: when we delete something, copies in our backups are overwritten within 35 days, and earlier versions of stored files within 30 days.
We may keep information longer if the law requires it, or if it is needed for a legal claim, and only for as long as that lasts.
Your rights
You can ask for a copy of the personal information we hold about you, and ask us to correct it, delete it, restrict how we use it, or send it to you or another organisation in a portable format. You can also object to how we use it. Some of these rights apply only in certain circumstances, and we’ll explain if one doesn’t apply to your request.
To make a request, email privacy@1stcyber.co.uk or use our contact form.
If you’re unhappy with how we’ve handled your information, please tell us first. You can also complain to the Information Commissioner’s Office at ico.org.uk/make-a-complaint or on 0303 123 1113.
Changes to this notice
We’ll update this notice when the way we handle personal information changes.
Last updated: 12 Oct 2026