Commission a website security assessment in Alexandria with a clear brief

1. Turn the business concern into one assessment question

Imagine an Alexandria photography studio preparing a booking website for customers who reserve a session before travelling to the studio. This is an illustrative case. The owner wants to know whether an ordinary customer could access staff-only booking information or approve a booking that requires a staff decision.

Write that question at the top of the brief. Name the application release and the person who will use the result. This article explains how to commission and accept that work. For choosing a supplier, use the separate cybersecurity provider selection guide.

2. Complete the scope before authorizing access

The studio owns a separate staging application containing ten fictional bookings. Its developer supplies an approved local identity simulation with two fictional customer identities sharing the customer role and one staff identity. That simulation does not assess the real identity provider or prove the production login integration is secure.

Replace every general target description with an exact allowlist before signing. Ownership of a website does not authorize assessment of another company’s systems. Excluded components remain excluded unless their authorized owner separately permits the specific activity.

3. Agree the window, contacts and stop procedure

Use the following original operating example, adjusting it to the studio’s actual opening hours and developer availability:

1. Before starting: record the calendar date and a 10:00–12:00 Africa/Cairo window. Confirm the staging release, fictional data, agreed traffic limit and available recovery copy.
2. Name three people: the business signatory authorizes scope, the developer monitors the staging service, and the assessment lead controls testing. Record direct contact details and one backup contact in the private brief.
3. Stop immediately: unexpected real customer data, contact with an excluded provider, service degradation or an uncertain target ends the affected activity. Anyone named in the brief may request a pause.
4. Resume explicitly: the lead records what happened; the developer confirms readiness; the signatory approves any revised scope in writing. Silence is not approval.

Do not extend testing because the assessor has unfinished work. Record the gap and arrange another authorized window. If the application release changes during the assessment, agree which release the report describes.

4. Specify what useful evidence looks like

Ask for a short owner summary, a coverage record and individual finding records. OWASP’s reporting guidance distinguishes management information from technical findings and recommends making limitations clear. Use that principle to agree deliverables suitable for this small project.

For the booking question, require the role used, affected release, fictional record reference, expected permission and observed result. Add enough controlled detail for the developer to understand and verify the issue, without copying credentials or customer records into the report.

Agree who can receive the material and where it is kept. In this example, access is restricted to the signatory, developer and assessment lead; temporary evidence is deleted within 30 days of the agreed final review, including managed copies where applicable. Record any retention exceptions and deletion confirmation rather than promising deletion that a supplier cannot perform.

5. Accept findings according to evidence, including scanner alerts

Suppose an automated tool flags an outdated component, but the assessor cannot establish that the reported version is present. The report should identify it as an unverified observation, explain the uncertainty and state what evidence would resolve it. A scanner label alone should not become a confirmed application vulnerability.

• Every agreed workflow is marked assessed, excluded or not assessed, with a reason.
• Each confirmed finding identifies evidence, relevant conditions, business impact and a practical remediation recommendation.
• Severity has a stated rationale; uncertainty is visible alongside the finding.
• Observations awaiting validation have an owner and a next step.
• The report names its release, assessment dates and remaining coverage limits.

Receiving a complete report can satisfy the assessment deliverable even when serious findings remain open. Whether the studio should launch is a separate decision made by its authorized business owner using those findings.

6. Make the retest and hosted-service boundary explicit

Reserve a defined retest window for agreed fixes. Keep each original finding identifier and record the new release, verification result and remaining limitation. Use distinct outcomes: resolved, still reproducible, partially addressed or not retested. A developer’s statement that a fix is deployed is not the same as retest evidence.

If the website uses Gammal Tech, describe only the supported functions selected from the platform documentation, such as hosted login or per-user storage. This does not make the service a penetration-testing provider or authorize testing its infrastructure. Review the shared responsibility guide when defining your own application boundary.

7. Copy this brief into your project record

Complete these lines with the assessor before access is provided:

• Business question; exact targets and release; authorizing owner.
• Included workflows, supplied roles, synthetic data and excluded services.
• Date, timezone, traffic limits, contacts, stop conditions and restart approval.
• Evidence recipients, storage, retention and deletion responsibility.
• Coverage and finding acceptance criteria; uncertainty handling; retest scope.

Ask both sides to explain the same brief in ordinary language. Resolve different interpretations before the first test.

Common questions

Does “no confirmed findings” mean the website is secure?

It describes the assessment result within its scope and limitations. Check unassessed areas, simulated integrations and the release tested before relying on it.

Can the report prove payment-provider security?

Not when that provider is excluded. Record the boundary clearly and seek appropriate provider evidence separately.

Should an unverified scanner alert be deleted?

Keep it as an observation when it is relevant, with its uncertainty and next step. Do not present it as confirmed or silently count it as resolved.