Safe, targeted test data for Guidewire PolicyCenter
Production PolicyCenter databases are large, full of personal data and slow to copy. Lower environments need the opposite. We cut PII exposure and build the exact scenarios your QA team tests, two ways, and help you choose between them.
Targeted subsetting
- Choose the exact policies QA needs by state, coverage, driver, vehicle, property, claims, billing or underwriting.
- A complete foreign-key walk keeps every parent and child record intact.
- Smaller datasets mean faster refreshes, lower storage cost and less PII to protect.
Best fit: lean, repeatable regression suites.
Full restore with scrubbing
- Production-like volumes and edge cases, restored into an isolated, restricted zone.
- Sensitive values are overwritten in place; keys never change, so referential integrity is untouched.
- Scrubs contacts, addresses, vehicles, drivers, MVR data, credentials and integration settings.
Best fit: performance testing and production-like UAT.
Data model fluency
Branches, FixedIDs, typelists and effective dating handled correctly, where naive subsetting goes wrong.
Privacy by design
Deterministic, format-preserving masking keeps VINs check-digit valid and age-based rating working.
Fits your configuration
We map your extension tables, not just the base data model, and validate against your schema.
Verified results
Row counts, orphaned-key checks, residual-PII scans and a clean application start, with evidence retained.
How we work
Discover your PolicyCenter version, lines of business and extension tables. Design the approach, scenarios and masking rules. Build parameterized subsetting or scrubbing scripts against a read replica or restricted copy. Validate integrity and privacy before release. Applies to self-managed (on-premises or IaaS) PolicyCenter.
Let's scope your next refresh →How we build PolicyCenter test data that holds up
For TDM engineers, data engineers, QA architects and DBAs. Applies to self-managed (on-premises or IaaS) PolicyCenter for Personal and Commercial Lines; Guidewire Cloud Platform does not provide the direct database access these approaches require. Table and column names are base-model examples, always validated against your own schema.
Choosing an approach
Option A: rules that prevent bad subsets
Seed, then stage
Seed from the policy period table and write the IDs to a staging table. Every later step joins to staging, not the original filter.
Choose branches deliberately
Every transaction creates a new branch. “No parent branch” is not “current”; use bound status with the most-recent-model flag, and pull ancestor branches when a selected branch is derived.
Join typelists, never hardcode
Typekey columns hold integer IDs that can differ between environments. Join to the typelist tables and filter on typecode.
Follow branch and FixedID links
Child tables link to the period by branch ID, and effective-dated entities reference each other by FixedID. Follow the data dictionary for each relationship.
Respect retired rows
Filter out retired rows wherever the column exists, and don't assume nothing is ever physically removed: drafts and purged data are.
Copy reference data whole
Typelists and admin data (users, groups, roles, producer codes, product and rate tables) are copied in full, and dimension filters use EXISTS so multi-vehicle or multi-location policies don't multiply rows.
Option A: the foreign-key walk
- Ancestor branches and their jobs (submissions, endorsements, renewals, cancellations).
- Policy and policy term.
- Account, account locations and addresses.
- Account contacts, roles, contacts and addresses.
- Policy lines and every line-specific table.
- Policy contact roles, locations and effective-dated fields.
- Coverages and risk entities: vehicles, drivers, dwellings, buildings, exposures.
- Underwriting issues, activities, notes, documents and history.
- All typelists and admin/reference data, in full.
- Client extension tables that reference branches, policies, accounts or contacts.
Extracts run against a read replica off-peak, then are validated: row counts per table, zero orphaned keys, zero missing typelist rows, and a clean application start. A subset larger than a few percent of production usually signals a missing filter. PII is masked before the subset leaves the secure zone.
Option B: full restore with scrubbing
Into an isolated, access-restricted zone; no access outside the data-protection group until scrubbing is verified.
In-place updates on a defined table set (about two dozen in a typical environment), run against the restored copy only.
Replace integration destinations, endpoints, credentials and emails so non-production can't reach customers or partners.
Residual-PII scans, row counts and an application start; retain evidence, then delete the unscrubbed restore.
What gets scrubbed
- Contacts and addresses, including pending contact updates.
- Vehicles and drivers: VINs, plates, license numbers, dates of birth.
- MVR results, license data and orders; third-party vendor reports.
- Credentials and session identifiers.
- Outbound integration configuration.
- Payment-plan summaries, affinity groups and legacy policy-change detail.
Design principles
- Deterministic: the same source value maps to the same masked value everywhere, including across PolicyCenter, ClaimCenter and BillingCenter.
- Format-preserving: valid VIN check digits, state license formats, shifted dates of birth so age bands still rate.
- Constraint-safe: unique indexes respected; primary keys, foreign keys and FixedIDs never altered.
- Discovery sweep: profile all text columns, notes, documents and history, and re-run after upgrades.
- Performance: batched updates, log monitoring, index rebuilds and statistics updates.
Ready to feel data confident?
