1. Definitions
1.1 Applicable Data Protection Law: all laws and regulations applicable to the processing of Personal Data under the Agreement, including, where applicable, the EU General Data Protection Regulation 2016/679 (“GDPR”), the UK GDPR, and the California Consumer Privacy Act as amended (“CCPA”).
1.2 Personal Data: any information relating to an identified or identifiable natural person that Site Qwality processes on Your behalf in connection with the Services.
1.3 Processing, Controller, Processor, Data Subject, and Supervisory Authority have the meanings given to them in Applicable Data Protection Law.
1.4 Subprocessor: any third party engaged by Site Qwality to process Personal Data on Your behalf.
2. Roles and Scope
2.1 As between the parties, You are the Controller (or, where You act on behalf of Your Clients as an MSP, a Processor) and Site Qwality is a Processor of Personal Data submitted to the Services.
2.2 Site Qwality will process Personal Data only on Your documented instructions, including with regard to transfers, unless required to do otherwise by law; in such a case, Site Qwality will inform You of that legal requirement before processing unless the law prohibits it. The Agreement, this DPA, and Your configuration and use of the Services constitute Your documented instructions.
2.3 Site Qwality also acts as a Controller in its own right for account administration, billing, its marketing websites, and its own security and audit records. That processing is described in the Privacy Policy and is outside the scope of this DPA.
3. Details of Processing
3.1 Subject matter and duration: the provision of the Services for the Term of the Agreement, until deletion of Personal Data in accordance with Section 9.
3.2 Nature and purpose: hosting, monitoring, alerting, observability ingestion and display (uptime checks, logs, metrics, traces, real user monitoring, session replay), status pages, notification delivery, billing, and support.
3.3 Categories of Data Subjects: Your Users (employees, contractors, consultants); end users of Your monitored websites and applications to the extent You configure the Services (for example real user monitoring or session replay) to collect data about them; recipients of notifications You configure, including recipients who hold no account with Site Qwality; people who subscribe to Your status pages; and any natural person identifiable from content You submit to the Services.
3.4 Categories of Personal Data: account and contact details (name, email address, phone number); authentication identifiers; notification destinations; the email address, confirmation state and timestamps of people who subscribe to Your status pages; IP addresses, session, browser-tab and anonymous visitor identifiers, device and browser metadata, page URLs and resource URLs, error messages and stack traces, and session interaction data collected by the SDK where You enable it; the request headers, response header map, response extract and resolved remote address recorded by each monitoring check, which includes any authentication header You configure on that check; the summary, severity, deduplication key, first link and outcome of each alert that Your other tools send to an alert source You create, and, only while You turn on a 24-hour debug capture for that source, up to 64 KB of each alert’s body with credentials and user, request, header, cookie, email address and IP address fields removed (the rest of the alert is not stored); and any Personal Data contained in logs, metrics, traces, or other content You submit to the Services. The Services are not designed for and must not be used to submit special categories of data as defined in Article 9 GDPR.
3.4.1 URL minimization, and where it does not reach. URLs collected by the SDK are stripped before storage, in the browser before transmission and again in the ingest service on receipt: everything from the first ? onwards is removed, and any user:password@ credentials are removed from the authority. Everything from the first # onwards is removed too, except that where You turn on hash routing, a hash route on a page URL, such as #/checkout, is kept like a path unless it contains = or &. The scheme, host, port and path are preserved exactly, so a URL carrying Personal Data in its path is stored as it is. The same rules are applied to URLs found inside error messages, stack traces, breadcrumbs, console messages, header values and attribute values, leaving the surrounding text and the line and column numbers intact. URLs inside a session replay recording, including the addresses of images, scripts and stylesheets in the recorded document, are stripped in the browser and again when the recording is compacted; until then, the uploaded recording keeps any query parameters You chose to allow. The context object You attach to an error or an action is Yours and is stored as sent, apart from field limits, the redaction of sensitive keys and this stripping. Four categories are outside that stripping: UTM campaign values, which the SDK reads from the query string of the first page of a session and stores as values; request and response bodies You choose to capture, which keep any URLs as sent; up to 64 characters of the text or label of an element an end user clicked, and its CSS selector; and a URL written without a scheme inside free text, which is deliberately not detected. Nothing in the stripping is a substitute for Your own obligation not to put Personal Data into a URL.
3.5 Session replay defaults, stated explicitly: where session replay runs, the Services record the rendered document of the pages Your end users view. Recording rules decide which sessions are replayed, and every application created today starts with three rules: replay every session in which an error occurs; replay an automatic sample of sessions lasting at least 3 seconds with an interaction, at a rate set from the application’s replay quota; and capture detailed session data, without replay, for 10% of sessions. You can change, disable or delete any rule. Your own page code can also start a recording with startReplay({ force: true }), which skips the rules and their sampling. When a replay rule could still match a session, the SDK records into the browser’s memory before the rule matches, holding roughly the last 60 to 120 seconds and about 5 MB at most; that buffer is uploaded only if a rule matches or the page forces a recording, and is otherwise discarded. No recording is made while consent is pending or refused, where Global Privacy Control is honored, after an end-user opt-out, or for a user on Your do-not-record list. Each application has a privacy level, and new applications start on Balanced. Strict masks all page text except elements You explicitly unmask, masks input values and replaces images, video, audio, picture and SVG elements with placeholders. Balanced masks input values and records page text, replacing email addresses, card-like numbers of 13 to 19 digits that pass the Luhn checksum, and runs of nine or more digits with asterisks. Relaxed masks input values and records page text as rendered. Page text is not masked by default under Balanced or Relaxed. An application created before privacy levels existed keeps a legacy setting, in which input masking and page-text masking are separate switches and no such patterns are applied. On that legacy setting, input masking was, until a recent fix, stored switched off on every application at the moment it was created, whether created in the dashboard or through the API. It stayed off unless someone opened that application’s privacy settings and turned it on. Site Qwality has not altered the stored settings of existing applications, so an older application You have not explicitly changed or moved to a privacy level is still recording most form input values unmasked, and You should check the setting on every application You operate. You are the Controller for this processing and it is Your responsibility to set the masking configuration You require and to establish a lawful basis for it.
3.6 Element-level control, stated per class because the three classes behave differently. Control is exercised through the mask, block and ignore-input selectors in each application’s privacy settings, and through three rrweb CSS classes. Add the classes to the element’s class attribute, for example <div class="rr-mask">. They are class names, not HTML attributes: <div rr-mask> has no effect.
rr-maskreplaces the text inside the element, and inside everything nested within it, with asterisks. It cascades to descendants, but it works only where the application applies no text masking of its own: no sensitive-data patterns, no mask selectors and page-text masking off, which means Relaxed or the legacy setting. Under Balanced, the default for new applications, and under Strict, the class has no effect by itself; to mask an element there, add.rr-maskor another selector to the application’s mask selectors. It masks text only: it does not mask input values, and it does not mask attributes such asplaceholder,alt,titleoraria-label, which are recorded as written apart from URL stripping.rr-blockstops the element being recorded at all. The recording keeps a blank placeholder of the same size and does not descend into it, so everything nested inside is covered too.rr-ignorestops input events being recorded on the element that carries the class. It does not cascade. The class is read from the element that received the event and nothing walks up the tree, so<div class="rr-ignore"><input name="ssn"></div>gives that input no protection at all; the class must be on the<input>itself. Even placed correctly it suppresses only later typing: a value already present in the field when the recording starts is captured in the initial snapshot unless input masking is on.
3.7 What input masking covers. When it is on, the value is replaced with one asterisk per character before it leaves the browser, for these input types and no others: color, date, datetime-local, email, month, number, password, range, search, tel, text, time, url and week, plus <textarea> and <select>. Whatever the setting, password, email and tel inputs are always masked, an <input type="hidden"> is never recorded at all, and when input masking is off, a field whose autocomplete attribute marks it as payment-card data is left out of the recording. Any other type outside that list keeps its value; a radio button or checkbox has its value string recorded unmasked alongside its checked state; and input masking never masks an element attribute, although URLs in attributes are stripped and, under Balanced and Strict, the sensitive-data patterns described in 3.5 are replaced in them. rr-unmask, data-sq-mask and data-sq-unmask do not exist in the recorder Site Qwality runs; earlier Site Qwality material described them and applying them changes nothing.
4. Confidentiality
Site Qwality ensures that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Every person and contractor with access to production systems has signed a written confidentiality undertaking.
5. Security
5.1 Site Qwality implements and maintains appropriate technical and organizational measures designed to protect Personal Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access, taking into account the costs of implementation and the nature, scope, context, and purposes of processing.
5.2 The measures in place as at the date of this DPA are:
- Encryption in transit for all connections between You and the Services. Every public API domain enforces a minimum of TLS 1.2 and the web properties redirect HTTP to HTTPS. This statement is scoped to customer-facing connections and is not a statement about every internal service-to-service hop.
- Encryption at rest for object storage and for the analytics data volume. All Site Qwality object-storage buckets use AES-256 server-side encryption with provider-managed keys and have public access blocked on all four settings; message queues are encrypted at rest; the storage volume holding logs, metrics, traces, real user monitoring and the replay index is encrypted. This is not a statement that every data store is encrypted at rest.
- Credential handling. Passwords are hashed with Argon2 and held by a specialist identity provider, which also issues sessions. Site Qwality verifies email challenges, authenticator-app codes and passkeys. API keys are persisted only as a one-way SHA-256 digest; the plaintext secret is never stored. Payment card data is captured entirely within the payment processor and never reaches Site Qwality systems.
- Multi-factor authentication, available to Your Users through authenticator-app codes and verified passkeys. Staff portal access also requires an allowed IP address and a staff role.
- Role-based access control across six dashboard roles (super admin, admin, billing admin, member, viewer and auditor), read from the verified session token. The admin and super admin checks also fall back to the role stored in Site Qwality’s database.
- Application-layer audit logging. Mutating authenticated requests are recorded with actor, action, method, path, result, request IP address and user agent, and are readable by You, including requests that were identified and then denied. That write is best-effort by design so that a logging failure can never fail the underlying request, which means a database outage can leave a gap in the log, and two endpoints that use a mutating method only to carry a read query are exempt. Site Qwality staff administrative requests made through its staff portal are recorded in a separate internal log; that log is not readable by You. These are application-layer records; they are not a claim about infrastructure-level access logging.
- Tenant scoping applied at the API layer before any storage read, and parameterised queries with bind values on the transactional database.
- Bot mitigation on the unauthenticated signup endpoint and request-rate throttling on every API gateway stage.
- Deletion protection on the production database, with automated backups retained for 7 days, and backups of the analytics store retained for 35 days (see Section 9.4).
5.3 This list is exhaustive. Where a measure is not stated above, You should not assume it is in place. Site Qwality holds no security certification of its own: there is no SOC 2 report, no ISO 27001 certificate and no published penetration test for Site Qwality. Certifications referenced anywhere in relation to the Services are those of Site Qwality’s infrastructure subprocessors. Further detail is published on the Security page.
6. Subprocessors
6.1 You provide general authorization for Site Qwality to engage Subprocessors. Site Qwality remains fully liable to You for the acts and omissions of its Subprocessors as if they were Site Qwality’s own.
6.2 The authoritative, dated and versioned list of Subprocessors is published at siteqwality.com/subprocessors/. That page carries a changelog so that a change can be identified and compared against the previous version. It supersedes any list embedded in an earlier version of this DPA or in any partner addendum.
6.3 The Subprocessors engaged for the Services are listed on the Subprocessors page (vendor, location and function). That page is authoritative if it and this clause differ.
6.4 Alert destinations You configure yourself (for example PagerDuty, Discord, Microsoft Teams, Telegram, or a webhook URL You supply), other than Site Qwality’s Slack app, are recipients You choose and contract with directly, not Subprocessors of Site Qwality. Telegram delivers alerts to the chat You link under Telegram’s own terms; Telegram offers no data processing agreement.
6.5 Site Qwality will give notice of any addition or replacement of Subprocessors by updating the Subprocessors page. The changelog on that page records the effective date of every change. If You object on reasonable data protection grounds within 14 days of a change being published and the parties cannot resolve the objection, You may terminate the affected Services in accordance with the Agreement.
7. Assistance
7.1 Taking into account the nature of the processing, Site Qwality will assist You by appropriate technical and organizational measures, insofar as this is possible, in fulfilling Your obligation to respond to requests from Data Subjects exercising their rights. If Site Qwality receives such a request directly, it will redirect the Data Subject to You where lawful to do so.
7.2 Site Qwality will assist You in ensuring compliance with Your obligations regarding security, breach notification, data protection impact assessments, and prior consultation with Supervisory Authorities, taking into account the nature of processing and the information available to Site Qwality.
7.3 What that assistance is today. The Services expose self-service export for HTTP check results, the monitor uptime summary and telemetry logs, and they expose deletion of a monitor, a real user monitoring application, a session filter and a source-map release. They do not expose deletion of an individual end-user session, replay, event or user identity, and they do not expose deletion of ingested log data by predicate. Assistance with those requests is a manual operation performed by Site Qwality staff against its databases and object storage on Your written request to privacy@siteqwality.com. Site Qwality will confirm to You what was deleted and when, so that You can evidence it to the Data Subject.
8. Personal Data Breach
Site Qwality will notify You without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data breach affecting Personal Data processed under this DPA, and will provide information reasonably available to it to support Your notification obligations.
9. Deletion and Return
9.1 What happens on termination today. On termination or expiry of the Agreement, or when You ask us to close Your account, Site Qwality marks the account deleted. That immediately ends access to the dashboard and the API. It does not by itself erase every stored copy of Personal Data. Records remain in Site Qwality databases and object storage until they either fall out of an enforced retention window (see the Data Retention page, which states category by category where a window is enforced and where none is in place today) or are deleted on request under Section 9.2.
9.2 Deletion on request. If You want Personal Data deleted rather than retained, ask us in writing at privacy@siteqwality.com. Deletion is executed as a manual operation across the transactional database, the analytics store, object storage and the relevant Subprocessors. Site Qwality will confirm the scope of what was deleted and the date it completed.
9.3 Return. Return of Your Data is available through the export functions the Services expose: HTTP check results, the monitor uptime summary, and telemetry logs. Any other category must be requested from Site Qwality and is produced manually.
9.4 Backups. Site Qwality keeps no backup for longer than 35 days. Backups of the analytics store, which holds logs, metrics, traces and real user monitoring data, are retained for 35 days from the point each backup is taken. Automated backups of the transactional database are retained for 7 days, and database and disk snapshots are deleted within 8 days of being taken. Personal Data erased from live systems can therefore persist in a backup for up to 35 days after erasure, after which that backup expires on its own schedule. Site Qwality does not restore a backup in order to re-apply an erasure.
9.5 Retention required by law. Site Qwality and its payment processor retain billing, invoice and tax records for the period required by law, notwithstanding a deletion request.
10. Audits
Site Qwality will make available to You information reasonably necessary to demonstrate compliance with this DPA and will allow for and contribute to audits, including inspections, conducted by You or an auditor mandated by You, no more than once per year, on at least 30 days notice, during normal business hours, and subject to reasonable confidentiality obligations. The parties agree that audits are first satisfied by written responses and by available third-party documentation. Site Qwality holds no audit report or certification of its own; the third-party documentation available to You is that of its infrastructure Subprocessors.
11. International Transfers
11.1 Site Qwality’s own infrastructure is in the United States, in the AWS us-east-1 region, except for the check locations described in 11.1.1 and a copy of published status pages kept in the AWS us-west-2 region, also in the United States. This covers the transactional database, the analytics store, all object storage other than that status page copy, and all serverless compute other than the execution of HTTP, TCP, ping and browser checks from a check location described in 11.1.1. That copy holds the same content the status pages publish and is served only if the primary copy cannot be reached.
11.1.1 Check locations. HTTP, TCP, ping and browser checks run from the check locations selected for each monitor. Where You select none, eligible paid uptime plans default to two healthy locations on different providers in the same country as the default location, subject to the account’s projected check quota. Other monitors default to one location. The default location is in the United States (AWS us-east-1), so both locations in the default pair are in the United States. Ping checks run only on Google Cloud locations; a ping monitor with no selected location runs from a Google Cloud location in the United States. A new browser check starts with the default location only. You can change the selected locations; a browser check can select Amazon Web Services locations only. TLS certificate, domain expiry and DNS record checks run in AWS us-east-1. If You select a location outside the United States for an HTTP, TCP or ping check, the monitored URL or host and the check’s configuration, including any headers, credentials or data to send that You configure on that check, are sent to that location, the request is made from it, and the check result, including the response received, is returned to the United States and stored there. If You select a location outside the United States for a browser check, the check’s script, including anything You write into it, is sent to that location and run there, and the check result, including its screenshots, HAR file and video, is returned to the United States and stored there. The available locations, each with its country and provider, are published at siteqwality.com/locations/. Check locations run on infrastructure provided by Amazon Web Services, Google Cloud and Microsoft Azure, each listed on the Subprocessors page, and any new Subprocessor is notified there as set out in clause 6.5.
11.2 There is no EU or UK data-residency option for storage. Selecting a check location outside the United States changes where that check runs, not where its result is stored. If Site Qwality brings another region into service for storage or processing, other than a check location You select under 11.1.1 or the status page copy described in 11.1, it will update the Privacy Policy and this DPA before doing so. Clause 11.1 is deliberately scoped to Site Qwality’s own infrastructure and is not a representation that no Personal Data is processed outside the United States: clause 11.4 acknowledges onward transfers, and the Subprocessors page states each Subprocessor’s location.
11.2.1 Content delivery. Site Qwality delivers siteqwality.com, the dashboard, status pages (including status pages on a customer’s own domain), public files, its MCP server and its internal staff portal through Amazon Web Services’ content delivery network. That network uses edge locations that include Europe, so a request originating in Europe is terminated in Europe. Status pages, the MCP server and the staff portal, which proxies staff requests to the API, carry customer data through those edge locations.
11.3 Where Personal Data protected by the GDPR or UK GDPR is transferred to Site Qwality in the United States, the parties agree that the European Commission Standard Contractual Clauses (Module Two or Module Three, as applicable) will apply and are available on request for execution, with Site Qwality as data importer and You as data exporter, together with the technical and organizational measures in Section 5. The UK Addendum applies to transfers subject to the UK GDPR where required. Site Qwality does not claim certification under the EU-US Data Privacy Framework.
11.4 Onward transfers to Subprocessors are listed, with their processing locations, on the Subprocessors page.
11.5 Representative in the EU and the UK. Site Qwality has not appointed a representative in the European Union under Article 27 GDPR, and has not appointed a representative in the United Kingdom. It does not intend to appoint either. Anything You or a Data Subject would send to a representative should be sent to privacy@siteqwality.com, or to Site Qwality’s registered postal address, both of which are published in the Privacy Policy.
12. Liability and Order of Precedence
The liability of each party under this DPA is subject to the limitations of liability set out in the Agreement. In case of conflict between this DPA and the Agreement with respect to the processing of Personal Data, this DPA prevails.