Women founder funding tool implementation: data controls

When planning women founder funding tool implementation, start with the smallest approved workflow. A funding platform should not receive every old spreadsheet, document and demographic field on day one. Prove the controls with dummy and limited pilot data before migration.

What to take away

Freeze the design

Write the purpose, users, tasks, fields, integrations, reports and excluded uses. Name controller and processor roles, system owner, data owner, security lead and accessibility owner. Approve supplier terms and assess the processing under the UK GDPR and Data Protection Act 2018. Under Article 35 of the UK GDPR, carry out a data-protection impact assessment (DPIA) where processing is likely to result in a high risk to people's rights and freedoms; follow the ICO's Data protection impact assessments guidance.

Keep equality monitoring, marketing, application assessment and research as separate purposes and access groups. A convenient shared field is not a lawful reason for everyone to see it.

Configure access and retention

Create roles for founders, advisers, reviewers, funders, researchers and administrators. Give the least access needed. Require strong authentication and review privileged accounts separately.

Set retention by record type: enquiries, incomplete applications, rejected cases, funded projects, research recordings, complaints and monitoring data. Test deletion, export and restoration. The ICO's IT supplier guidance recommends enforceable supplier security, periodic review and exit planning.

Use the NCSC's cloud security principles to structure evidence on identity, separation, operational security and secure administration.

Clean migration data

Inventory sources, owners, duplicates, stale records, permissions and special fields. Remove information without a continuing purpose. Reconcile founder, company and provider identifiers rather than matching people from names alone.

Run a sample migration. Check counts, missing values, relationships, dates, access and deletion flags. Keep the old system read-only for a defined reconciliation period, then close access under the approved plan.

Test real journeys safely

Use the Web Content Accessibility Guidelines (WCAG) at level AA as an accessibility benchmark. Test journeys on mobile, by keyboard and screen reader, and on low bandwidth. Include assisted completion without exposing answers to unrelated staff.

Attempt prohibited actions: export all applicants, view demographic data from an adviser role, reactivate a deleted record and share a file outside the team. Record whether controls prevent or log them.

Train by role

Teach each group its tasks, data boundaries, escalation and manual fallback. Researchers should not see lender assessment notes; advisers should not edit monitoring responses; administrators should not interpret eligibility.

Use scenario exercises rather than a feature tour. Require users to correct a record, respond to a withdrawal and report a suspected incident.

Run a limited pilot

Set duration, user volume, success measures and stop thresholds. Monitor completion, accessibility problems, permission errors, duplicate records, support time, incorrect eligibility, withdrawals and incidents. Ask pilot founders about clarity and control, not just convenience.

Approve wider rollout only after high-risk defects are closed and data reconcile. Keep a manual route for deadlines and supplier outage.

Operate and exit

Review access, integrations, subprocessors, retention, complaints and supplier changes on a schedule. Reassess after a new product, investor partner or demographic use.

Maintain an export and transition test. A tool is not safely implemented until the service can leave it without losing evidence or retaining data indefinitely.

Approve the release gate

Require evidence that the configured journey matches the privacy notice, eligibility policy, equality analysis and supplier contract. Reconcile migrated totals and inspect a sample record in every role. Confirm that optional demographic fields can be skipped without changing an unrelated finance outcome.

Publish support, adjustment, complaint and data-rights contacts before invitations are sent. Give the operations team a clear status page and an outage message that does not promise a deadline extension controlled by an external funder.

For the first two weeks, review high-risk logs daily and founder feedback after each completed journey. Pause intake if users can see the wrong files, an eligibility rule rejects an approved case or an inaccessible step has no assisted route.

Close the pilot with signed acceptance, a defect register and scheduled access review. Unresolved low-risk items still need owners.

Before you act

Common questions

What should be done before migrating any data?

Implement the smallest approved workflow first and prove controls with dummy and limited pilot data. Freeze the design, configure access and retention, and clean migration data by inventorying sources, removing information without a continuing purpose and reconciling identifiers rather than matching people from names alone.

How should access and retention be configured?

Create roles for founders, advisers, reviewers, funders, researchers and administrators, giving the least access needed. Require strong authentication and review privileged accounts separately. Set retention by record type, such as enquiries, incomplete applications, rejected cases, funded projects, research recordings, complaints and monitoring data, and test deletion, export and restoration.

What must happen before wider rollout is approved?

Approve wider rollout only after high-risk defects are closed and data reconcile. Keep a manual route for deadlines and supplier outage. Require evidence that the configured journey matches the privacy notice, eligibility policy, equality analysis and supplier contract, and reconcile migrated totals and inspect a sample record in every role.