A website compliance audit is a scoped review of how a website collects data, communicates with visitors and implements relevant controls. The output should be a dated list of evidence-backed findings, uncertainties and next actions. It is not a certificate of legal compliance. This guide is general information, not legal advice.
01 · Scope
Decide what the audit can actually see.
Record the domain, relevant subdomains, release or commit, and the journeys under review: browsing, account creation, purchases and data requests. List which pages and states were examined, including signed-in and signed-out views where applicable. Keep excluded areas explicit.
A public URL shows rendered pages and response headers; source code can reveal implementation details that a crawler cannot. Neither alone proves how production settings, staff processes or vendor contracts work. SafeLaunch’s URL scan reads the submitted page and up to eight same-site pages; it does not log in, submit forms or run payments. Repository and uploaded-code reviews provide a different evidence set. See the documented audit method.
02 · Context
Choose markets from facts, not the domain name.
Write down where the business operates, where users are located, which audiences it targets and what data it handles. Note children’s use, health or financial information, regulated professions and third-party providers. A hosting location or country-code domain is not enough to determine which laws apply.
For example, GDPR Article 3 describes territorial scope, including circumstances involving organizations outside the EU. Applicability and exceptions require the underlying facts to be assessed; choosing a jurisdiction in a tool is a starting point, not a legal conclusion. Compare the coverage map and versioned rulebook, then ask a qualified professional about unresolved questions.
03 · Evidence
Build a small, reproducible evidence packet.
Keep a page list, review date, release identifier, redacted screenshots and relevant configuration details. Record browser and device context when behavior depends on them. Use test accounts and synthetic data; never put live credentials or customer records in a shared report.
- Data collection
Forms, uploads, account fields, collection purposes and destinations.
What data is necessary, who receives it, and how long is it retained?
- Privacy information
Published notices, actual vendor settings and owner-confirmed data practices.
Do the promises on the website match what the service actually does?
- Cookies & tracking
Analytics, advertising and replay services; behavior before and after visitor choices.
Where consent is required, do the choices control the relevant tracking?
- Security
HTTPS, sampled response headers, access controls and source/configuration review.
Is personal data exposed, and can someone access another user’s records?
- Accessibility
Form labels, keyboard journeys, focus states and assistive-technology testing.
Can people complete the important journeys without a mouse or visual-only cues?
- Sector & audience
Target markets, professional services, children’s use and sensitive data.
Which additional requirements need a specialist’s review?
04 · Triage
Separate observations from assumptions.
For each finding, capture the observed condition, its page or file location, affected users or data, the relevant requirement and what remains uncertain. “This sampled response lacks a header” is an observation. “This website breaches a law” is a much broader conclusion that a missing header alone cannot establish.
Investigate active exposure of sensitive data and unauthorized access first. Then consider likelihood, impact, reach and dependencies—not only the effort needed to fix an issue. A privacy notice that promises one practice while production does another deserves a different response from an isolated formatting problem. Scanner scores help organize work; they are not legal pass/fail verdicts.
A practical finding record contains: evidence, requirement, impact, confidence, owner, proposed action and the test needed to close it. The sample report shows how SafeLaunch presents cited findings and remediation options.
05 · Verification
A fix is complete when the relevant journey works.
Assign an owner and a target date. Make the change in a controlled environment, then repeat the original check and test adjacent states. For a consent issue, examine behavior before a choice, after rejection and after acceptance. For an access-control issue, check both the authorized user and a different account. For accessibility, include keyboard and assistive-technology checks; automated checks alone do not establish accessibility conformance.
Save the new version and test evidence, note unresolved assumptions, and record any residual risk. Repeat the review after meaningful changes to code, vendors, data collection, audiences or launch markets. A dated report describes the reviewed scope and version, not every future release.
06 · Limits
Know when to bring in a specialist.
Automated review cannot confirm all contracts, retention operations, international transfers, staff practices or server-side behavior. It may miss authenticated journeys, dynamic states and pages outside the sample. A published notice does not prove that a deletion request is fulfilled or that a vendor is configured as described.
Involve a qualified lawyer for uncertain legal applicability, regulated professions, children’s services, sensitive data at scale or a regulator inquiry. Use security and accessibility specialists where manual assessment is needed. Read the full SafeLaunch disclaimer before relying on a report.