Skip to main content

Overview

This runbook covers the manual process for provisioning a new broker tenant on PensionsPortal.ie. Each broker firm operates as an isolated tenant — they can only access their own employers, pension schemes, and member data. Tenant provisioning is currently a manual admin operation. A self-service broker onboarding flow is planned but not yet implemented.
This runbook is intended for PensionsPortal.ie engineering staff and SuperAdmin operators. Do not share this document with broker firms.

1. Tenant Model Overview

In PensionsPortal.ie, a “tenant” maps to one broker firm. The data hierarchy under a tenant is:
Tenant isolation is enforced at the service layer via ActorContext — every query is filtered by brokerId. A broker user cannot read, write, or enumerate any data belonging to a different broker. See the Multi-Tenancy Architecture for the full isolation model.

2. Pre-Provisioning Checklist

Complete all items before beginning the provisioning steps:
  • Data Processing Agreement (DPA) signed with the broker firm
  • Broker firm legal name and Companies Registration Office (CRO) number confirmed
  • Primary contact email address confirmed (this becomes the BrokerAdmin login)
  • Primary contact full name confirmed
  • Agreed billing plan confirmed (and payment method set up if applicable)
  • Subdomain or white-label domain requirements noted (future — not yet implemented)
  • Broker firm has been briefed on GDPR responsibilities as a data controller
Do not provision a tenant without a signed DPA. PensionsPortal.ie processes personal data on behalf of the broker. Processing without a DPA in place violates GDPR Art. 28.

3. Provisioning Steps

Step 1 — Connect to the production database

Step 2 — Generate a broker ID

The broker is identified by a brokerId UUID that is stored on all associated users, employers, schemes, and members.
Record the generated brokerId in the provisioning log for this broker. You will need it throughout this procedure and for future support requests. A dedicated broker admin UI at /admin/brokers is a planned roadmap item. Until implemented, the brokerId is the primary identifier for all support queries.
There is currently no separate brokers table — the brokerId is a bare UUID propagated across the users, employers, schemes, and related tables.

Step 3 — Create the BrokerAdmin user account

Generate a secure temporary password:
Insert the user record:
Never reuse temporary passwords across tenants. Generate a unique temporary password for each new broker provisioning. The broker must change this password on first login. Note: A forced first-login password change flow is a planned roadmap item. Until implemented, instruct the broker verbally or in the secure credential delivery message to change their password immediately.

Step 4 — Communicate credentials securely

Send the following via a secure channel only. Do not send credentials over plain email. Acceptable channels:
  • 1Password Secure Share link (expires after first view)
  • Bitwarden Send (single-use, time-limited)
  • Encrypted email (if broker has PGP key on file)
Message template:

Step 5 — Verify access

Log in to the portal as the new BrokerAdmin and confirm all of the following: Isolation checks — CRITICAL:
  • The BrokerAdmin can see zero employers initially (clean slate)
  • The BrokerAdmin cannot navigate to or view any other broker’s employers, schemes, or members
  • Attempting to access another tenant’s resource returns a 403 or empty result, not their data
Functionality checks:
  • BrokerAdmin can create a new employer
  • BrokerAdmin can create a pension scheme under that employer
  • AI Compliance Assistant responds to queries
  • Email notification received when a test member is enrolled (confirms Resend integration)
  • Audit log records all test actions (check via SuperAdmin audit view or direct DB query)

Step 6 — Log provisioning in the audit trail


4. Failure and Rollback Plan

If the provisioning procedure fails or must be abandoned mid-way: Step 1 — Identify the last successful step by checking what records exist in the database. Step 2 — Remove partially-created records:
Step 3 — Log the rollback:
Step 4 — Diagnose the failure, then retry from Step 1 with a new brokerId.

5. Post-Provisioning Verification Checklist

Complete this checklist and retain a copy in the provisioning log: If any check fails, do not hand the account over to the broker. Investigate, resolve, and re-run the full verification before proceeding.

6. Off-Boarding (Broker Departure)

When a broker firm ends their contract with PensionsPortal.ie, follow this procedure to fulfil GDPR data return and erasure obligations.
Pension scheme compliance records (scheme documents, contribution histories, KFH filings) are subject to a statutory 7-year retention period under Irish pensions legislation. You must NOT delete scheme-level records — only anonymise the personal data of individual members. Confirm retention obligations with legal before proceeding.
Step 1 — Export all broker data:
Step 2 — Deliver export to broker via secure channel (1Password Secure Share or encrypted email). Step 3 — Anonymise all member PII following the GDPR Art. 17 procedure in Backup & Restore Runbook:
Step 4 — Disable all broker users:
Step 5 — Retain scheme compliance records (do not delete — statutory retention applies):
Step 6 — Log off-boarding in audit trail:
Post-off-boarding checklist:
  • Data export delivered to broker and receipt confirmed
  • All member PII anonymised (names, emails, phone numbers, PPS numbers, dates of birth)
  • All broker user accounts set to Disabled role (cannot log in)
  • Scheme compliance records confirmed retained (statutory 7-year hold)
  • Off-boarding logged in audit trail
  • DPO notified for GDPR Art. 30 records of processing update
  • Billing subscription cancelled