Mobile
penetration testing.

Yes. Scoping, findings and reports all live in the client portal, so the first step is an account for your organisation. You don’t need one to ask us a question first: send an enquiry, and we can set up your organisation’s account from it, with a draft request filled from your enquiry for you to check before you submit it.

Yes. An authoriser can ask us on the Organisation page in the client portal, or you can ask your 1ST Cyber contact, and we add them to your organisation’s account; they set their own password from a link that works once, within 24 hours. Only people your organisation names as authorisers can authorise testing: whoever registered your organisation is one, as is the first person we invite to the portal from your enquiry, and an authoriser can ask us in the portal to let a colleague authorise too. The Organisation page in the portal shows who can authorise and, for anyone we let authorise later, since when; when email notifications are on, every authoriser is also emailed when it’s granted. If you forget your password, ask us for a new link.

If you tick Network, the online form asks first which network test you need: external, internal or both. It asks for your organisation and contact details, and the assets to test: paste your URLs, hostnames, IP addresses, ranges or app store links, one per line, and we detect each one’s type. For each asset you say who hosts it, whether it’s in scope or excluded, and whether testing it needs sign-in. The form also asks for the environment, any authentication requirements, your objectives and anything to exclude. You can also say when testing can take place (the dates, daily hours, and whether testing must not take place outside them), add testing rules, such as techniques we mustn’t use, and leave notes for your testing team. For each service you tick, the form also asks that service’s own questions, each with why we ask, and you can answer “Not sure”. If a third party, such as a cloud provider, hosts an asset you want tested, we need their permission before we can agree the scope: attach it as a supporting document, or confirm that you hold it, on the Scope tab. We may also ask you for further items, such as a document or an answer, each with the reason we need it and what follows if you can’t provide it; we accept each one, or return it with the reason, and you can tell us if one isn’t available. Once you submit, we ask in the same way for what each service you ticked needs, which its page lists under “What we’ll ask you for”.

No. Your organisation’s profile, on the Organisation page in the client portal, holds your contacts, emergency contacts, standard exclusions, preferred testing hours and notes for testing teams, and each new request starts from it. You can also start a request from the information of an earlier engagement’s authorised scope: its assets, environment, access, objectives, exclusions and testing rules fill the form, and you confirm each section is still correct. Each IP address, range, cloud account and asset another company hosts comes unticked: you confirm it is still yours or remove it before you save. If that scope was authorised more than 6 months ago, the form says so. An older scope’s special requirements go in the notes for your testing team, and you move any limit among them to the testing rules before you save. Documents we accepted on earlier engagements are kept in your organisation’s document library, and you can use one again on a new request: it is copied and checked for malware again first. Nothing is authorised until you authorise the new request.

Yes. Upload it as a PDF or Word (.docx) file instead of completing the form, and list the key assets it covers; your contact details are taken from your account. It must pass a malware scan before you can submit it.

Only after your testing team has reviewed the scope and you’ve approved and authorised that version in the client portal. Before you authorise, you add who we should phone if something urgent happens during testing. 1ST Cyber then books the testing dates, daily hours and lead tester in the portal, and you’re told when they’re booked or moved. Testing starts only on a booked day, inside the booked hours, once the lead tester has confirmed they’ve read the version you authorised and the items needed before testing are done. If you set dates and hours that testing must not go outside, we book and start only inside them, and while a third party’s permission for an asset you host with them is current. When that window ends during testing, the testing team is alerted the next time the portal is used rather than at that moment, so to stop testing at once, phone us. If a third party’s permission expires during testing, testing stops on that asset until you renew it in a new scope version. We send you the addresses we test from before testing starts, so you can allowlist them.

If testing needs sign-in, the client portal shows a test access card for each asset that needs it once you authorise testing, and we may ask for more. Don’t paste passwords, keys or tokens into the portal. Send them by encrypted email (for example Microsoft 365 message encryption), with the password sent separately (for example by text or phone call), then mark the card as provided: the portal records only that access arrived and works, never the credentials. Once the report is delivered, you can keep test access for retests or tell us you’ve disabled it.

Changing what we may test, how, or within which dates creates a new version of the scope, which you review and authorise. If a change removes or limits anything we may test, testing stops at once and doesn’t start again until you have authorised the new version. If we propose a change, or you only add to what we may test, we keep testing only within the version you last authorised until you authorise the new one. You can stop testing at any time. Every change is recorded.

Yes. Contact details, emergency contacts, your engagement’s title, notes for your testing team, and the dates and daily hours you’d prefer for testing can be updated at any time without a new scope version. Dates marked “Testing must not take place outside these dates” are part of what you authorise, so changing them needs a new version. On a request made before notes and daily hours had fields of their own, they are part of its special requirements, which only a new version changes, and its other details are changed with Edit details on the engagement’s Overview, since saving its scope makes a new version. Every change is recorded, and your testing team is told.

Yes, at any time while testing is authorised, booked or under way, and during a retest. Phone 1ST Cyber’s emergency number first, so that testing stops at once. Then press Stop testing in the client portal and give a reason: that withdraws your authorisation, records who stopped testing and why, and alerts your testing team in the portal. Testing restarts only when you authorise again, and the work already done stays on record and can still be reported. During a retest the button is Stop retest: it stops that retest at once and alerts your testing team, your authorisation stays as it is, no result tested after the stop is recorded, and the retest continues only when you request it again.

Yes, until testing starts. Choose Withdraw request in the client portal and give a reason. A withdrawn request can’t be restarted, so start a new request if you need testing later. Once testing has started, a request can no longer be withdrawn: the engagement ends with a report on the work done.

People in your organisation with a client portal account, the penetration testers assigned to your engagement and 1ST Cyber administrators. Your organisation sees the findings once the report is approved and published, on the engagement and in the findings history on the Organisation page. When we test for you again, the testers assigned to the new engagement can also see your earlier published findings 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.

Request a retest in the client portal. Someone in your organisation who can authorise testing confirms the request, with the dates it may take place. Your testing team records the retest result, with the check they performed when it passes; it appears once a second person at 1ST Cyber has released it, and the finding is resolved only when the retest passes. If you decide to accept a risk instead, you record who approved it, why and when it will be reviewed, and we show it as accepted, never as resolved.