Personal data boundaries

Before setting personal data boundaries

Use this page before running or 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 Project Pages public and authorized.
• Use `project_pages_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 project domain.
• Stop when `PERSONAL_DATA_BOUNDARY`, `PRIVATE_PATH_EXCLUDED`, `SCAN_SCOPE_BLOCKED` or `PERSONAL_DATA_REDACTION_REQUIRED` applies.

Keep public pages and exclude private data

Follow the path `Project → Project Pages → Public URL groups → Excluded paths → Run scan or stop`.

1. Open `/projects/{project}` and find Project Pages before running a scan. Result: discovered public groups and excluded paths are visible before any scan runs.
2. Check `project_pages_status` and `personal_data_boundary_status`. Result: the project shows whether public pages are ready or blocked by private data risk.
3. Keep only public pages that the customer is authorized to test, such as home, product, pricing, public checkout information, policy and support pages. Result: the scan 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 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 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 Project Pages review when the boundary is ready, or Unsupported targets when the safe public boundary cannot be confirmed. Result: the next action is either a 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.
• Discovered same-domain URLs 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 scanning, retesting or sharing evidence.

• Boundary ready means `personal_data_boundary_status` is ready, `project_pages_status` is ready and private paths are excluded with reasons.
• Public pages ready means `project_pages` 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.
• Boundary blocked means `SCAN_SCOPE_BLOCKED` or `PERSONAL_DATA_BOUNDARY` stops the scan until the customer chooses safe public pages.

Continue after personal data boundary

When the boundary is ready, continue to Project Pages review or Data collected and excluded. If the boundary 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.