How OpenForAll processes website evidence on a customer’s instructions

The customer is controller and VHUG Technologies OÜ is processor for personal data incidentally present in customer-selected scan targets and resulting evidence. Processing begins when a user with access requests a scan and continues while evidence is retained under the package or until lawful deletion or return.

• Service: browser-based accessibility scanning and remediation evidence
• Purpose: detect, explain, track, and verify accessibility issues
• No use for advertising or an unrelated OpenForAll purpose
• Controller responsibilities remain with the customer

The selected website, scan scope, schedule, users, package retention, remediation actions, exports, and support requests form the customer’s documented instructions. OpenForAll rejects private-network targets and does not add authenticated scanning unless separately configured and approved.

• Only owned targets or targets the customer has permission to assess
• Bounded pages, redirects, time, and request volume
• Customer controls direct and agency access
• Unlawful instructions should be identified before processing where permitted

Data subjects may include website visitors, customers, staff, applicants, authors, or other people whose information appears in rendered content. Data can include names, identifiers, contact details, account-facing text, images, page URLs, technical metadata, and any special-category data the customer exposes on the scanned page.

• OpenForAll does not need special-category data to perform a scan
• Customer should use non-production or minimised content where practical
• Focused screenshots and short HTML excerpts reduce evidence scope
• Raw results and page metadata may remain necessary for reproducibility

People assigned to administer the service must be bound to confidentiality and receive access only as needed. Application access is scoped by organisation, role, direct membership, and capped agency relationship; customer evidence is not exposed to unrelated tenants.

• Unique user accounts and password hashing
• Role-checked server-side operations
• Client workspaces remain isolated
• Security and administrative events are attributable

Current measures include target and redirect validation, private-network blocking, isolated browser contexts, bounded scans, CSRF protection, secure sessions, login throttling, tenant access controls, focused evidence, non-public artifact storage, retry-safe queues, integrity-checked backups, dependency gates, and worker/scheduler health monitoring.

• Secrets stay outside source control and tenant exports
• Artifacts are served only after access checks
• Backups have manifests and SHA-256 verification
• Production encryption, hosting, recovery, and access procedures require final documentation

Stripe is used for OpenForAll’s own billing but is not intended to receive scan evidence. Production hosting, transactional email, and backup providers may process customer or user data and must be listed with location, purpose, safeguards, and notice/change procedure before this schedule can be executed.

• No unlisted production subprocessor should receive scan evidence
• Equivalent data-protection duties must flow down by contract
• Customer objection and change-notice process remains to be defined
• Transfers outside the EEA require an identified lawful mechanism and safeguards

OpenForAll will use available product controls and reasonable information to assist with data-subject requests, security obligations, impact assessments, regulator consultation, and evidence about processing. Suspected personal-data breaches must be investigated and communicated to the customer without undue delay using the final incident contact process.

• Tenant export and owner-only deletion impact preview
• Auditable access, remediation, billing, and preference events
• Customer remains the response owner for scanned website content
• Incident timing, escalation contacts, and report format remain launch requirements

Organisation exports provide structured customer records and artifact references. Package expiry removes eligible artifacts through an audited retention process, but full organisation deletion is intentionally not executable yet. At termination, OpenForAll must return or delete processor data unless law requires retention and must make compliance information available without exposing other customers or security-sensitive details.

• No false claim that lock equals deletion
• Shared user identities require ownership-aware handling
• Backups need bounded expiry and deletion propagation
• Audit cooperation should be proportionate and protect other tenants

Before signature, OpenForAll must attach the final controller details, selected service/package, production subprocessor schedule, hosting and backup locations, transfer safeguards, technical and organisational measures, deletion schedule, incident contacts, audit process, and signature or electronic acceptance record.

• Versioned final agreement
• Named parties and approved signers
• Completed schedules rather than placeholders
• Accepted copy retained for both parties