Chapter 34 — Employment, SaaS and Global Enterprise Services Sector Playbook

1. Two surfaces, not one blanket authority

Most enterprises run both an employment estate and a cloud-services estate. The employer processes recruitment, payroll, benefits, security and exit information. The SaaS provider hosts another organisation’s records while processing its own billing and account-security information. Those activities can share systems without sharing a legal role or processing ground.

The common discipline is precise scope. “We employ the person” cannot justify any later use; “the customer signed our contract” cannot justify every provider purpose. A useful programme records whose data, which activity, who determines purpose and means, on whose behalf processing occurs, and which ground or conditioned exemption actually applies. The role and ground are linked decisions, not synonyms.

The chapter uses the canonical retained commencement schedule. Core DPDP processing obligations and rights are scheduled for 13 May 2027, on the assumption that the retained Gazette schedule remains unchanged (COMM:19,49–59).[2] The relevant Rules have their own deferred tranche and corrected publication language (RULES:1005–1010; CORR:25–38).[3][4] Future-case controls are readiness designs, not claims that all private-sector duties or Board powers already operate on the September 2026 review date. Existing labour, tax, sector and information-security obligations still require their own applicability decisions.

2. Employment is s7(i), without invented sub-limbs

Section 7(i) covers employment purposes or those related to safeguarding the employer from loss or liability, with examples including corporate espionage, confidentiality of trade secrets, intellectual property, classified information, and a service or benefit sought by a principal who is an employee (ACT:326–329).[1] It does not contain numbered recruitment, assessment, onboarding and exit limbs. Section 7(h) instead concerns disaster or public-order assistance; changing its label to employment would change the legal ground, not merely a citation (ACT:321–329).[1]

Employee consent requires care because workplace dependency can undermine genuine choice. That is not a rule that employee consent is always invalid or that every HR activity must use s7(i). Section 6(1)‘s actual consent conditions must be met where consent is used (ACT:206–218).[1] For payroll and necessary employment administration, the hypothetical employer records a fact-specific s7(i) assessment. For an optional employee publication or separate service, it assesses whether the same clause genuinely reaches the facts or a freely chosen, necessary-data consent route is appropriate. A coercive checkbox is not a fallback when the legitimate-use analysis fails.

Safeguarding is bounded by the purpose and facts, not by the ambition of the monitoring product. The author-recommended workpaper asks what loss or liability the control addresses, why the selected signals are relevant, who may inspect them, how false allegations are handled and when use stops. Those are implementation safeguards, not invented statutory words. In particular, s6(1)‘s necessary-data wording should not be cited as though it literally governs every s7(i) activity; minimisation across the estate is the author’s design recommendation unless another applicable provision imposes it.

Consider security telemetry collected to investigate unauthorised access. A proposed productivity league table made from the same events is a separate purpose assessment. It is not automatically excluded because the employee did not request analytics, nor automatically covered because it might benefit management. The employer must establish the actual employment/safeguarding connection and other applicable constraints. Where that evidence is missing, the proposed reuse remains stopped. The chapter does not invent a general legitimate-interest balance to approve it.

3. Recruitment: resolve facts instead of manufacturing certainty

SUB-003 is the Company’s hypothetical unsuccessful adult applicant, distinct from employee SUB-002. Recruitment may raise a fact-specific s7(i) interpretation because the clause refers to employment purposes while one statutory example expressly refers to a principal who is an employee. The wording does not create the former manuscript’s categorical “recruitment limb” (ACT:326–329).[1] This chapter preserves that application question honestly. PUR-014’s applicant assessment is unresolved in the base dossier, not approved by a generic HR label.

There are practical options. The employer can seek a reviewed interpretation for the specified hiring activity or design a genuinely applicable consent/voluntary-provision route where the necessary facts support it. A submitted CV may support a specified requested hiring use under s7(a), but not every purchased profile, scraped inference or later talent-pool use; s7(a) requires the principal’s voluntary provision and no indication of non-consent (ACT:269–284).[1] The decision record should show the actual route, not list several possible grounds as if uncertainty itself were authorisation.

For an AI screener, a correct ground is only the first gate. The employer needs an account of which personal data affects the decision, its completeness, accuracy and consistency, and the separate authority for any model-training use. Section 8(3) applies to decision-affecting personal data; it is not a certificate of unbiased hiring or a blanket right to deploy any scoring model (ACT:338–342).[1] The proposed release is paused when the applicant ground is unresolved or a material input is disputed. The specimen does not claim that a screener shipped, that bias disappeared, or that an accuracy audit ran.

Group-company reuse is another failed branch. Sending unsuccessful applicants to a sister company’s marketing or recruitment pool is not simply continuing the original employer’s selection process. Establish the receiving entity’s role, the new purpose and actual authority. Group ownership is not a universal processing ground. The proposed base-case export is denied; a future separately grounded process can be reviewed without rewriting the original applicant record as if it had always included that permission.

4. Retention is a record-class decision, not an HR lookup number

The former six-month, two-year and seven-year HR windows are withdrawn as unsupported statutory claims. No exact labour instrument, jurisdiction, record class or trigger had been established for them. Their removal is not proof that such periods never occur in any legal regime. It prevents the deletion engine from treating unexplained numbers as law.

Section 8(7) qualifies erasure for necessary legal retention. In the future operative branch, r8(3) adds its minimum one-year processing/data/log retention for Seventh Schedule purposes and subsequent qualified erasure; r6(1)(e) separately addresses security evidence (ACT:351–359; RULES:1101–1106,1153–1166).[1][3] These are not seven years of active HR analytics. The programme must distinguish purpose authorisation, access to retained records and eventual physical disposal. An unresolved period is not permission to retain indefinitely; it is an owned decision that prevents falsely claiming the record is ready for disposal or new reuse.

An author-recommended retention record contains the source provision, applicable entity/jurisdiction, record class, event from which the period runs, minimum, disposal condition, hold scope, permitted use and next review. The filled example deliberately uses unresolved rather than a fabricated legal date where the particular employer’s labour/tax facts are absent. The operator may not replace that state with a default number because a software field requires one.

A legal hold also requires authority and scope. Section 17(1)(a) concerns processing necessary to enforce a legal right or claim; the common s17(1) effect preserves s8(1),(5) while disapplying the stated other provisions (ACT:523–546).[1] An asserted possible future dispute is not automatically such a claim. Counsel should record the actual facts and necessary data, then review when that necessity ends. The proposed hold does not permit marketing, model training or unrestricted manager access. It also should not be confused with HOLD-001 in the lending dossier, which remains scoped to disputed loan records rather than being repurposed as an HR hold.

5. Employee rights need a component-level response

Employees are Data Principals, but ss11/12 expressly concern processing for which prior consent was given, including s7(a). A record processed solely under s7(i) does not acquire those particular statutory rights simply because it sits in the same HR database as a consent-based record (ACT:441–476).[1] The rights service therefore evaluates access, correction and erasure by processing activity. It does not promise blanket ss11–14 access to every internal record, nor use the distinction to ignore all employee concerns.

Section 13’s grievance mechanism and s14 nomination need their own scope and procedure; a nominee exercises the principal’s rights on the qualifying death/incapacity event, rather than creating broader rights or replacing the subject (ACT:477–495; RULES:1294–1318).[1][3] The Rules’ reasonable published grievance-response period must not exceed ninety days. That is not a universal statutory response SLA for every access, correction or erasure request (RULES:1308–1314).[3] An employer can voluntarily offer broader transparency or correction services, subject to other constraints. It should label those as policy services and avoid promising that an unqualified statutory duty compels disclosure of another person’s information.

In the hypothetical SUB-002 compound request, the service separates an optional consent-based benefit record from payroll processed on the stipulated employment ground. It handles the first’s s11/12 eligibility, evaluates any retention exception, and routes the second through the employer’s voluntarily extended service and any other applicable rights. A possible inaccurate payroll input is still operationally important; the data-quality duty may apply independently of that particular request right. The response explains the component decisions and offers the grievance channel without claiming a blanket refusal is satisfactory.

The internal service also needs independent handling. A manager whose conduct is disputed should not alone decide the employee’s request. That is an author-recommended conflict safeguard. It supports the book’s evidence discipline without pretending the Act specifies the precise HR ticket routing or approval hierarchy.

6. The SaaS provider’s roles are per activity

The original “two-hat” discussion assigned fiduciary status to hosted CRM data merely because the provider supplied the software, then processor status to a downstream module because it used another contract. That rule is withdrawn. Under the statutory definitions, actual purpose/means and acting on behalf decide the roles; contract layers cannot create a contrary factual relationship (ACT:65–81,330–337).[1]

The recommended contractual schedule includes permitted processing, safeguards, supplier changes, incident escalation, cessation/erasure cooperation and evidence. Section 8(2) requires its valid-contract relationship, while the broader operational schedule is the author’s implementation design (ACT:335–337).[1] A dual audit log does not by itself satisfy the law. The log must correspond to actual permitted actions and preserve denied or incomplete operations, rather than record two nominal approvals for the same unsupported reuse.

Consent references are particularly easy to overstate. A customer organisation’s administrator signing a service contract is not necessarily every hosted person’s affirmative consent. The provider must know whose instructions it follows and where evidence of the relevant authority is held. A transmitted hash is a reference, not transferable universal permission. Rechecking a known hash without checking purpose, subject, scope and current state can approve the wrong activity perfectly consistently.

7. Foreign services: geography and exemption facts

Section 3(a) concerns processing within India and includes later-digitised data; s3(b) reaches outside-India processing connected with offering goods or services to principals within India’s territory. It is not a nationality rule (ACT:135–157).[1] An Indian citizen outside India and a non-citizen within India therefore cannot be classified solely by passport. The relevant territorial, offering and activity facts must be recorded.

CASE-104 / ENT-104 is a separate fictional Indian SaaS exporter. It hosts contacts of principals not within India pursuant to a contract with a person outside India. Under those stipulated facts, s17(1)(d) may apply. The common s17(1) effect exempts the stated Chapter II provisions except s8(1),(5), Chapter III and s16; it does not erase responsibility and safeguards (ACT:523–546).[1] The example is conditional, not a universal exemption for “export revenue.” If a hosted contact is within India, that record fails the stipulated territorial branch. Provider billing, own-product analytics and unrelated support telemetry need their own assessment rather than inheriting the hosted-data conclusion.

For in-scope non-exempt flows, s16(1) concerns notified transfer restrictions; s16(2) preserves higher protection/restrictions under other Indian law. Rule 15 concerns Government requirements for making data available to foreign States or their controlled entities/agencies. Rule 13(4) adds a distinct conditional SDF specified-data/traffic restriction (ACT:515–522; RULES:1287–1290,1319–1323).[1][3] None is a blanket statement that all DPDP personal data must remain in India or that all overseas cloud processing is free of conditions.

The Company lending case has a concrete sector contrast: the retained NBFC Credit Facilities Directions paragraph 14(4) requires India server storage for the covered digital-lending data and states the return/deletion requirement within twenty-four hours where processing occurs outside India (RBI-NBFC:311–315).[6] Do not import that requirement into every SaaS tenant. Do not ignore it for covered borrower data because a general DPA permits offshore support. The proposed control maps dataset, tenant/activity, remote access, backup and supplier paths before approving a route. A persistent foreign backup is not made compliant merely by re-papering it as “processing.”

8. B2B contacts and the support-access counterexample

A named procurement contact can be personal data even when the customer is a company. A generic shared mailbox may present different identifiability facts; the word “B2B” is not itself an exclusion (ACT:113–114).[1] Suppose the individual voluntarily sends her work contact details to request a demonstration. A bounded s7(a) decision may support that requested follow-up if its conditions hold. Purchasing a list from a broker, obtaining another employee’s details from the administrator, or scraping a discoverable email does not establish the same voluntary-provision facts. Public availability has its own s3(c)(ii) conditions, not a universal internet exception (ACT:146–157,269–284).[1] The proposed marketing expansion is refused until its own authority is established.

Now consider offshore support. A support engineer can view production data remotely without a bulk export. The recommended flow map records that access alongside replicas and backup locations. For the Company’s covered borrower data, the sector constraints matter; for CASE-104’s qualifying hosted foreign-person records, the exemption analysis differs. One global toggle cannot express both decisions.

The worked change record contains a route pending approval rather than an invented surgical repair completed in a week. It requires access restrictions, an identified alternative, evidence of actual configuration and retest. If support capacity is inadequate, that is an unresolved operational cost, not permission to bypass a binding restriction. A supplier’s contractual promise is evidence of a promise; only observed execution can establish that the new access control actually works.

9. Use the pack without overstating it

The populated sector overlay and decision records are linked in out/sector/README.md. Their local fixtures check employee-rights scope, unresolved applicant authority, mixed SaaS roles, foreign-services conditions and refusal of independent reuse. No live employee records, SaaS credentials or production telemetry are involved. The exact run output is distinct from the hypothetical input decisions.

For a reader exercise, take one contact appearing in hosted CRM, provider billing and a proposed training set. Write three activity decisions, not one person-wide role. Then change the contact’s territorial facts and introduce a narrow legal claim. Explain which exemption, right and retention decisions change and which safeguards survive. Any answer relying only on “employment,” “B2B,” “cloud” or “consent hash present” has omitted the work.

The unresolved real-world inputs are employer jurisdiction and applicable record-specific instruments, applicant interpretation, actual monitoring purpose, supplier execution and current transfer/sector orders. The source-backed legal mappings are no longer left to invented statutory limbs or unnamed retention requirements. Chapter 35 can now assemble the Company’s distinct decisions without silently turning it into an insurer, hospital or global CRM fiduciary for every hosted record.

Source locator key

Ranges above are physical newline lines, starting at 1; PDF form feeds do not add lines. Full source URLs follow. The retained text and hashes are indexed in out/remediation/Q06/source-index.json.

• ACT: research/legal/evidence/01_dpdp_act_2023_gazette.txt.
• COMM: research/legal/evidence/02_gsr_843e_commencement.txt.
• RULES: research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt.
• CORR: research/legal/evidence/06_gsr_892e_corrigendum.txt.
• RBI-NBFC: research/sector/q06-evidence/rbi-nbfc-credit.txt.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — ACT [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — COMM [3] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — RULES [4] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — CORR [6] https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12957 — rbi-nbfc-credit

Contents · Reader guide and citation conventions · Artifact index