Personal data boundaries

Before setting personal data boundaries

Use this page before accepting scan scope, before retesting a page that may show personal data, and before sharing evidence with a provider or client. Standard WebRiskOps workflows should stay on customer-authorized public pages and should exclude account-specific, employee-only or private personal data.

• Keep scope public and authorized
• Use `accepted_scope_status`, `personal_data_boundary_status` and `excluded_path_reason` before starting or retesting.
• Keep personal data boundaries tied to the account, project, client workspace and accepted domain.
• Stop when `PERSONAL_DATA_BOUNDARY`, `PRIVATE_PATH_EXCLUDED`, `SCAN_SCOPE_BLOCKED` or `PERSONAL_DATA_REDACTION_REQUIRED` applies.

Keep public scope and exclude private data

Follow the path `Project → Scan scope selection → Public URL groups → Excluded paths → Accept scope or stop`.

1. Open `/projects/{project}` and find Scan scope selection before accepting scope. Result: discovered URL groups, manual URLs and scope acceptance controls are visible before any scan runs.
2. Check `accepted_scope_status` and `personal_data_boundary_status`. Result: the project shows whether public scope is ready or blocked by private data risk.
3. Select only public pages that the customer is authorized to test, such as home, product, pricing, public checkout information, policy and support pages. Result: accepted scope stays focused on public customer-facing paths.
4. Add `excluded_paths` for account, admin, employee, order history, inbox, saved payment method, logout and private client pages. Result: each skipped private path has an `excluded_path_reason`.
5. Remove URLs that require login, expose customer records or display personal form submissions. Result: `PRIVATE_PATH_EXCLUDED` prevents those pages from becoming scan evidence.
6. If a discovered or manual URL unexpectedly shows personal data, stop the scan or retest and use Privacy redaction when an artifact already exists. Result: `PERSONAL_DATA_REDACTION_REQUIRED` is handled before evidence is shared.
7. Keep `PERSONAL_DATA_BOUNDARY` visible when public and private content cannot be separated safely. Result: the workflow stops instead of expanding scope into private data.
8. Before publishing, exporting or creating tickets, compare report evidence with Data collected and excluded. Result: provider tickets and shared reports do not include customer records, private account data or personal form values.
9. For agency work, confirm the account, project and client workspace match the authorized customer. Result: personal data from one client cannot appear in another client report or export.
10. Continue to Accepted scan scope when the boundary is ready, or Unsupported targets when the safe public scope cannot be confirmed. Result: the next action is either an accepted scan or a clear stop state.

Public pages that can stay in scope

Public pages can stay in scope when they are accessible without private credentials and do not expose customer-specific records.

• Home, landing, product, service, pricing, FAQ and public support pages.
• Public checkout information pages that do not expose saved payment methods or customer account data.
• Public policy, trust, documentation and contact-routing pages.
• Public CMS or storefront pages that belong to the accepted domain and account.
• Synthetic manual URLs on the accepted domain when they are public and customer-authorized.

Paths and data to exclude

Excluded paths should stay out of scans, artifacts, reports and ticket exports.

• Account settings, order history, invoices, saved addresses, saved payment methods and support inboxes.
• Admin dashboards, employee tools, staging systems, internal applications and private client portals.
• Logout paths, password reset flows, one-time links and session-specific URLs.
• Form submissions, uploaded files, customer records, personal messages and private identifiers.
• Any third-party domain or client workspace that the customer has not authorized for the selected project.

Ready and blocked personal data states

Use these states before accepting scope, retesting or sharing evidence.

• Boundary ready means `personal_data_boundary_status` is ready, `accepted_scope_status` is accepted and private paths are excluded with reasons.
• Public scope ready means `accepted_scope` contains only customer-authorized public pages for the current project.
• Private path excluded means `PRIVATE_PATH_EXCLUDED` explains why a private or account-specific path is not scanned.
• Redaction required means `PERSONAL_DATA_REDACTION_REQUIRED` or `redaction_status` must clear before evidence is published, exported or ticketed.
• Scope blocked means `SCAN_SCOPE_BLOCKED` or `PERSONAL_DATA_BOUNDARY` stops the scan until the customer chooses a safe public scope.

Continue after personal data boundary

When the boundary is ready, continue to Accepted scan scope or Data collected and excluded. If the scope is blocked, use Unsupported targets to explain why the workflow stops, Privacy redaction when an artifact already contains personal data and Customer responsibilities to confirm authorization before the next scan.