1. Define the question and the scope.
Write down why you are commissioning the assessment and who will use its findings. A release decision, a concern about customer access and a review of internet-facing systems may lead to different testing priorities. Identify important workflows and information rather than relying only on a list of hostnames.
Build an initial inventory of the domains, applications, endpoints or network assets you want considered. Distinguish systems you control from services provided by someone else. Record exclusions and areas that need particular care so they can be discussed before a proposal is finalised.
2. Establish written permission and contacts.
Confirm who has authority to approve testing for each part of the environment. Hosting, cloud and managed service arrangements can introduce additional requirements. Owning an account on a third-party service does not by itself establish permission to assess the provider's infrastructure.
Agree on the testing window, permitted activities, exclusions and a contact who can make operational decisions. Establish how either side will pause testing and how urgent findings will be shared. Make sure the people who operate the environment know the arrangements that affect them.
3. Prepare representative access.
For an application, discuss the user roles, authentication flows and workflows that matter. Suitable test accounts and example records may be needed to examine boundaries between roles or organisations. For a network, agree on where testing will originate and any access setup required.
If testing will use a non-production environment, identify material differences from production. If production is in scope, discuss operational sensitivities and suitable data handling arrangements. Verify access before the agreed window so basic setup does not consume assessment time.
- An agreed asset and workflow inventory, including exclusions.
- Test accounts for the roles being assessed and a secure way to share access.
- Relevant application or API documentation where available.
- Named operational contacts and a pause or escalation process.
- A suitable approach to test data, evidence and report access.
4. Agree on the report and follow-up.
Tell the assessor who will read the report. Business owners need context for decisions, while developers and system administrators need enough detail to investigate and fix issues. Clarify the delivery method, findings discussion and any requirements for sharing the report with another party.
Decide who will own remediation and how fixes will be tracked. Discuss retesting separately: which findings it covers, what access will be required and how its results will be recorded. An original test date does not automatically reserve a later retest window.
5. Keep the first enquiry simple.
You do not need to send credentials to begin a scoping conversation. Describe your business, the systems involved, your main concerns and any timing constraints. Blackcube Solutions will discuss scope, permission and suitable information-sharing arrangements with you.
Use the checklist as a starting point, then adapt it to the engagement. The final written scope and agreed working arrangements are the reference for what testing can take place.
Further reading.
- NIST SP 800-115Background on planning, conducting and following up security assessments.
Discuss the right scope.
These services can support a conversation about your systems and assessment goals.