Enterprise onboarding

Onboarding produces an approved control boundary, not a marketing “readiness score.” Trial/demo tenants contain synthetic data only and cannot connect production systems.

Day zero — request and tenant

The request form asks work email, organisation, role, sector, deployment interest and consent to be contacted. It says: “Do not enter customer, employee, Aadhaar, PAN, health or account data.”

After commercial/security review:

1. create tenant name and immutable tenant ID;
2. verify an email/DNS domain;
3. select India time zone and data-hosting/deployment profile;
4. name tenant owner and backup owner;
5. require MFA before setup continues;
6. display data-processing/product terms and product boundary.

Duplicate verified domains enter review; they are not auto-merged.

Day one — organisation and governance

Legal entity form

Field	Type / validation
registered name	text, 2–200 characters
entity type	controlled list + “needs review”
CIN/registration	optional encrypted field; pattern hint, no false validation
India presence	establishment / offers goods or services / neither / uncertain
brands and business units	repeatable, names unique within entity
sector/licences	instrument-driven controlled list, registration and expiry
roles	Fiduciary / Processor / SDF candidate/designated / CM readiness
privacy/grievance contact	monitored email/phone/address, test required
DPO	required only by configured designation/policy

Selecting SDF designated requires a notification source. Selecting statutory Consent Manager creates a separate readiness workspace; it does not change public status.

Identity and access

Configure OIDC or SAML SSO, SCIM, MFA, session policy, IP rules, service accounts and one sealed break-glass user. Test login and deprovision before inviting broad users. Map IdP groups to least- privilege roles; privileged roles require explicit assignment and expiry.

First week — inventory and controls

• import legal entities, systems, vendors and processing activities from validated templates

  ;

• choose sector packs and confirm applicability;

• approve top purposes and current notices;

• configure request/grievance and incident contacts;

• connect metadata-only scanner or generic webhook in test mode;

• define five critical record classes and retention sources;

• run one synthetic withdrawal and rights request;

• record skipped items with risk owner and target date.

Imports show a dry-run diff. Errors identify row/field and do not partially commit unless the user chooses valid rows with an auditable decision.

First month — readiness and go-live

The checklist requires:

• two-person approval of entity and role model;
• production SSO/MFA/SCIM and break-glass test;
• approved purpose/notice versions;
• processor and system owners;
• incident contact and tabletop;
• rights identity and manual fallback;
• retention/hold/deletion rehearsal;
• evidence export verification;
• deployment backup/restore test;
• security and privacy acceptance.

“Go live” is disabled for critical failures. A legal reviewer and tenant owner sign the configuration version. The UI says “Operational configuration approved,” not “DPDP compliant.”

Setup states

trial → security_review → provisioned → configuring → review_pending → approved → live

Terminal/branch states: rejected, expired, suspended, offboarding, deleted. A suspended tenant preserves evidence and blocks new processing actions except incident/exit operations.

Error and recovery

• SSO lockout: sealed break-glass with alert and post-use review.

• SCIM deletes last owner: reject and notify.

• connector credentials fail: remain test/pending; never save a secret in audit text.

• source data is stale: show source time and disable destructive actions.

• import collision: require merge/new/skip decision per stable external ID

  .

• deployment loses network: queue signed connector operations with bounded expiry and replay.

Offboarding

Customer selects export formats/destination, freezes changes, resolves holds, revokes integrations, exports configuration/evidence, deletes tenant stores and search/cache, expires backups and obtains subprocessor results. deleted is set only when completion is verified; lawful support/security records are listed with source, purpose and expiry.

Acceptance criteria

• Given a synthetic trial, when a user attempts a production connector, then policy blocks it.
• Given SSO setup, when SCIM would remove the last owner, then the change fails safely.
• Given SDF designated, when no source is supplied, then approval is unavailable.
• Given an import with three invalid rows, then the dry run shows exact errors and no hidden partial write occurs.