How to audit an assessment vendor for SOC 2, GDPR, DPDP Act 2023, and data residency compliance

The short answer

Enterprise assessment platform procurement increasingly requires compliance audit discipline that goes well beyond reviewing the vendor's compliance certifications page. SOC 2 reports vary substantially in scope and depth. GDPR compliance depends on specific processing arrangements that vendor marketing typically obscures. DPDP Act 2023 compliance is a new and rapidly evolving requirement for any vendor processing personal data of Indian residents. Data residency claims need verification against actual infrastructure architecture, not vendor assertions about where they can host data.

The audit discipline isn't about ticking certification boxes. It's about verifying that the vendor's architectural decisions, operational practices, and contractual commitments produce compliance posture that holds up under regulatory audit, enterprise security review, and the specific compliance requirements your organisation operates under. The audit happens during procurement, not after deployment, because compliance gaps discovered after the platform is operationally deployed are expensive to remediate and may force vendor changes that the procurement decision should have prevented.

This guide walks through the audit discipline across four compliance dimensions: SOC 2 reporting and what to verify, GDPR processing arrangements and the questions that reveal compliance depth, DPDP Act 2023 requirements and how to evaluate Indian-resident data handling, and data residency verification beyond vendor claims.

Why compliance audit during procurement matters more than after deployment

Three patterns produce enterprise procurement decisions that fail compliance audit later. Each reflects a different misunderstanding of what compliance verification actually requires.

Pattern 1: Treating compliance certifications as binary signals. Many procurement processes treat compliance certifications as binary - the vendor has SOC 2, therefore the vendor is compliant. The structural problem: SOC 2 reports vary substantially in scope. A SOC 2 Type I report covers a point-in-time assessment with limited control evaluation. A SOC 2 Type II report covers a multi-month operational period with substantive control testing. A SOC 2 report scoped narrowly to specific systems may not cover the systems your organisation will actually use. The binary framing misses these substantial variations.

Pattern 2: Accepting vendor compliance claims without verification. Vendor compliance pages typically list certifications, regulatory frameworks the vendor aligns with, and data protection commitments. The structural problem: many of these claims are unverified or aspirational rather than audited. GDPR-compliant without specifying processing arrangements means little. SOC 2 in progress means the vendor doesn't currently have SOC 2 and has variable timeline to achieving it. DPDP Act 2023 compliant without specific verification means the vendor has reviewed the act but may not have implemented the requirements operationally.

Pattern 3: Postponing compliance review until after vendor selection. Some procurement processes select vendors based on functional capability and price, then engage compliance review only after the procurement decision. The structural problem: compliance gaps discovered late are expensive - they force vendor switches, delay deployment, or require vendor remediation work that the procurement leverage no longer supports. Compliance review during procurement, when vendor leverage is highest, produces dramatically better outcomes.

The honest framing: compliance audit during procurement is the moment of highest leverage for ensuring the vendor relationship produces the compliance posture your organisation requires. The audit discipline upfront prevents the operational consequences that emerge when compliance gaps surface during regulatory review or security audit.

Dimension 1 - SOC 2 reporting and what to verify

The first audit dimension is SOC 2 - the Service Organization Control 2 reporting framework that has become the de facto compliance standard for SaaS vendors handling sensitive customer data.

The questions that reveal SOC 2 substance:

Is the report Type I or Type II? SOC 2 Type I reports describe controls at a point in time - the vendor has designed controls and they exist on the report date. SOC 2 Type II reports describe controls operating over a multi-month period - typically 6 or 12 months - with substantive evidence that the controls actually operated effectively. Type II reports are dramatically more useful for compliance assurance because they verify operational reality, not just design intent. For enterprise procurement, accept only SOC 2 Type II reports from vendors handling sensitive data. Type I reports indicate vendors who have started the SOC 2 journey but haven't completed it.

What's the report's observation period? SOC 2 Type II reports cover specific observation periods. A report covering a six-month period from 18 months ago provides less assurance than a recent 12-month report. The observation period should be recent (typically within the last year) and substantial (12 months is preferable to 6 months). Vendors who provide reports with observation periods more than 18 months old are signalling either weak audit discipline or delays in their certification programme.

What's the report's scope? SOC 2 reports specify which systems and services the audit covered. Reports scoped to specific products may not cover the products your organisation will use. Reports scoped to specific environments may not cover the production environment serving your data. Verify that the report's scope explicitly includes the services you'll consume. Vendors with broad reports covering their entire platform are more useful than vendors with narrowly scoped reports.

Which Trust Services Criteria are included? SOC 2 reports cover five Trust Services Criteria - Security (always required), Availability, Processing Integrity, Confidentiality, and Privacy. The Security criterion is mandatory; the others are optional. For most enterprise procurement, you should expect Security and Availability at minimum, and Confidentiality for vendors handling sensitive data. Privacy criterion inclusion is increasingly important for vendors handling personal data. Reports limited to Security alone are signalling weaker compliance posture than reports covering multiple criteria.

What exceptions or qualifications appear in the report? SOC 2 reports document exceptions - control instances where the audit found weaknesses or non-compliance. A clean report with no exceptions is ideal but rare. Reports with documented exceptions should be reviewed for severity and remediation status. Vendors who resist sharing the full report (sharing only the executive summary) are typically hiding exceptions that matter for procurement decisions.

What's the auditor's reputation? SOC 2 auditors range from Big Four accounting firms (Deloitte, PwC, EY, KPMG) to mid-tier specialised firms to small auditors of variable reputation. Auditor reputation affects the reliability of the audit findings. Vendors audited by reputable firms with established SOC 2 audit practices produce dramatically more reliable reports than vendors audited by small unknown firms.

Has the vendor remediated previously identified exceptions? Multi-year SOC 2 reports show whether previously identified exceptions have been remediated. Vendors who consistently fail to remediate exceptions in subsequent reports are signalling operational weakness that procurement should weight heavily.

What's the relationship between SOC 2 and ISO 27001? Some vendors carry both SOC 2 and ISO 27001 certification. ISO 27001 covers similar territory through a different framework (international standard with annual surveillance audits and three-year re-certification cycles). Vendors with both certifications are typically operationally mature; vendors with only one are typically earlier in their compliance journey. For Indian and European markets, ISO 27001 is sometimes preferred over SOC 2 due to international recognition.

The evaluation discipline: request the full SOC 2 Type II report (not just the executive summary or marketing claims), review the scope and observation period, examine exceptions and remediations, verify the auditor's credentials. Vendors who resist sharing the full report under NDA are signalling that the report contains content that wouldn't survive procurement scrutiny.

Dimension 2 - GDPR processing arrangements and compliance depth

The second audit dimension is GDPR - the General Data Protection Regulation that applies to vendors processing personal data of European Union residents, regardless of where the vendor is based.

The questions that reveal GDPR substance:

What's the vendor's role - controller or processor? GDPR distinguishes between data controllers (who decide why and how personal data is processed) and data processors (who process data on behalf of controllers). Assessment vendors are typically processors, with the customer as controller. This distinction matters because controllers and processors have different obligations under GDPR. The vendor should clearly identify themselves as processor in their Data Processing Agreement (DPA).

Does the vendor offer a standard Data Processing Agreement (DPA)? GDPR Article 28 requires controllers to have written processing agreements with processors. The vendor should offer a standard DPA that meets Article 28 requirements - data categories, processing purposes, processing duration, controller-processor obligations, sub-processor handling, data subject rights, security measures, audit rights, breach notification, post-termination data handling. Vendors without standard DPAs are signalling early-stage GDPR compliance.

How does the vendor handle sub-processors? Most SaaS vendors use sub-processors - cloud infrastructure providers, monitoring services, support tools. GDPR requires the vendor to disclose sub-processors, obtain customer consent for sub-processor changes, and ensure sub-processors meet GDPR requirements. The vendor should maintain a published sub-processor list with notification procedures for changes. Vendors who can't provide a sub-processor list are operationally unprepared for GDPR.

What's the vendor's stance on international data transfers? GDPR restricts personal data transfer outside the EU/EEA. The vendor needs a legal basis for any such transfers - typically Standard Contractual Clauses (SCCs) following the EU Commission's 2021 templates, or adequacy decisions for specific countries. Vendors who process EU data outside the EU should have explicit SCC arrangements and supplementary measures addressing the Schrems II requirements for data transferred to third countries (particularly the US).

How does the vendor handle data subject rights requests? GDPR grants data subjects specific rights - access, rectification, erasure, portability, restriction, objection. The vendor should have operational procedures for handling data subject rights requests that come through the customer (the controller). Vendors who can't articulate their data subject rights procedure clearly are operationally unprepared.

What's the breach notification procedure? GDPR requires data breaches affecting personal data to be reported within 72 hours. The vendor should have explicit breach notification procedures with timelines. Vendors who don't have clear breach notification SLAs (e.g., notification within 24 hours of vendor awareness) are signalling weak operational discipline.

What security measures protect personal data? GDPR Article 32 requires appropriate technical and organisational measures to protect personal data. The vendor should articulate specific security measures - encryption (in transit, at rest, in processing), access controls, audit logging, vulnerability management, incident response. Vague "we implement appropriate security measures" language signals operational depth that may not exist.

How is post-termination data handled? GDPR requires processors to delete or return personal data at the end of the processing relationship. The vendor's DPA should specify the post-termination data handling - deletion timelines, deletion verification, data return options. Vendors with vague post-termination language create ongoing compliance risk.

What's the vendor's GDPR audit posture? Customers (as controllers) have audit rights under GDPR. The vendor should have a clear audit process - what audits the vendor supports, what documentation is available, what audit fees apply. Vendors who resist customer audits are signalling that audit-level scrutiny would reveal compliance gaps.

The evaluation discipline: review the DPA in detail, verify sub-processor disclosure, confirm SCC arrangements for international transfers, examine breach notification SLAs, evaluate the post-termination data handling, understand the vendor's audit support. Vendors with substantive GDPR compliance can support detailed verification; vendors with surface-level compliance resist detailed examination.

Dimension 3 - DPDP Act 2023 requirements for Indian-resident data handling

The third audit dimension is the Digital Personal Data Protection Act 2023 (DPDP Act 2023) - India's data protection legislation that applies to vendors processing personal data of Indian residents.

The DPDP Act is newer than GDPR and rapidly evolving through subsequent rules and regulations. Vendor compliance maturity varies dramatically because many vendors are still building DPDP-specific compliance operations.

The questions that reveal DPDP Act 2023 substance:

Has the vendor designated a Data Protection Officer (DPO)? The DPDP Act requires significant data fiduciaries (large-scale data processors) to designate DPOs. The vendor should have a DPO with specific responsibilities for DPDP compliance. Vendors without designated DPOs are operationally unprepared for DPDP requirements.

What's the vendor's notice and consent architecture? DPDP Act requires explicit notice to data principals (the individuals whose data is processed) and consent that meets specific requirements - clear, informed, freely given. The vendor's notice and consent architecture should align with DPDP requirements. Vendors who handle consent through generic privacy policies are signalling weaker DPDP alignment.

How does the vendor handle data principal rights? DPDP Act grants data principals rights - access, correction, erasure, grievance redressal, nominate a person in case of incapacity. The vendor should have operational procedures for handling these rights. Vendors with mature DPDP compliance can articulate their rights procedure clearly; vendors at early stages cannot.

What's the vendor's data localisation posture? DPDP Act allows the Indian government to restrict cross-border data transfers to specific countries through subsequent regulations. The current state of cross-border restrictions remains evolving, but vendors operating in the Indian market should have data residency capabilities that allow Indian data to remain in India when required. Vendors who can only process Indian data in non-Indian regions are creating future compliance risk as DPDP rules evolve.

How does the vendor handle children's data? DPDP Act has specific provisions for processing children's data (under 18) - verifiable parental consent, restriction on tracking and targeted advertising. For hiring assessments involving candidates under 18 (campus hiring in some contexts), the vendor's children's data handling matters. Vendors without specific children's data procedures are operationally unprepared.

What's the breach notification timeline? DPDP Act requires breach notification to the Data Protection Board and to affected data principals. The vendor should have explicit DPDP-specific breach notification procedures. Generic breach procedures may not satisfy DPDP-specific requirements.

How does the vendor handle the upcoming DPDP rules? The DPDP Act has been enacted but specific rules and timelines for various provisions continue to be released. Mature vendors track the regulatory evolution and update their compliance posture as rules emerge. Vendors who treat DPDP as a one-time compliance project rather than ongoing operational discipline are signalling weak compliance maturity.

Is the vendor's compliance documentation available in operationally useful form? Vendors who provide substantive DPDP compliance documentation - privacy policy mapping to DPDP provisions, data handling procedures, breach procedures, rights handling procedures - support customer compliance work. Vendors with thin or generic documentation transfer compliance risk to customers.

The evaluation discipline: this is the dimension where vendor compliance maturity varies most dramatically because DPDP is still emerging. Vendors who are operationally mature on DPDP have explicit DPDP-specific compliance programmes; vendors who treat DPDP as a generic GDPR-equivalent are typically missing DPDP-specific requirements.

Dimension 4 - Data residency verification beyond vendor claims

The fourth audit dimension is data residency - where the vendor actually processes and stores customer data, as distinct from vendor claims about where data can be hosted.

The questions that reveal data residency substance:

Where is candidate assessment data actually stored? The vendor should be specific about data storage regions - AWS Mumbai region (ap-south-1), Azure India Central, Google Cloud Mumbai. Vague claims like "we support data residency" without specific regions are marketing language that doesn't verify operational reality.

Where is data processed during assessment delivery? Storage location and processing location can differ. Some platforms store data in one region but process it in another for performance or cost reasons. The processing location matters for compliance - data processing in unexpected regions can violate data residency commitments. Verify both storage and processing locations explicitly.

Where does AI processing happen for AI-enabled features? AI-powered features (AI proctoring, AI tutoring, AI assessment generation) typically involve sending data to AI service endpoints. The endpoints may be in different regions than the rest of the platform. For data residency commitments to hold, AI processing should occur in the same region as the rest of the data. Vendors using AI services in different regions (typically US-based AI APIs) without explicit residency controls create data residency gaps.

Where are backups stored? Production data residency commitments often don't extend to backup data, which may be stored in different regions for disaster recovery. The backup region matters for compliance - backup data containing personal data is still personal data under GDPR and DPDP Act. Verify backup region commitments explicitly.

Where does customer support access data? Customer support teams accessing customer data for support purposes may be located in different regions than the data storage. Vendors with support teams accessing EU or Indian data from non-EU/non-Indian regions need explicit access controls and audit logging to maintain residency commitments.

Are sub-processors aligned with data residency commitments? Vendor sub-processors may operate in different regions than the primary vendor. Data residency commitments need to extend to sub-processor data handling. Verify that sub-processors handling customer data operate in compliant regions.

What's the vendor's technical enforcement of residency commitments? Verbal residency commitments without technical enforcement are operationally fragile. Strong vendors have technical controls that prevent data from leaving designated regions - IAM restrictions, encryption key location controls, infrastructure-level region boundaries. Weak vendors rely on operational discipline alone.

Are residency commitments contractually binding? The Master Services Agreement (MSA) and DPA should specify data residency commitments contractually. Verbal or marketing-language commitments are not legally enforceable. Verify contractual residency commitments before procurement.

How is residency verified operationally? Strong vendors provide some form of operational verification - audit logs showing data locations, dashboards showing processing regions, periodic attestation. Weak vendors rely on customer trust without verification.

The evaluation discipline: data residency claims need verification at the architectural and contractual level. Vendors who can articulate specific regions, sub-processor locations, AI processing locations, and technical enforcement mechanisms have substantive data residency capability. Vendors who rely on marketing language about "flexible data residency" without specifics are signalling architectural decisions that may not support actual residency commitments.

How to actually structure the compliance audit during procurement

A framework worth working through:

1. Document your specific compliance requirements before vendor evaluation. Different organisations operate under different compliance requirements based on industry, geography, customer base, and regulatory environment. Document your specific requirements explicitly. Vendor evaluation against generic compliance produces decisions that may not match your actual compliance posture needs.

2. Request comprehensive documentation under NDA. Vendors should provide full SOC 2 Type II reports, standard DPAs, sub-processor lists, security architecture documentation, and data residency commitments under NDA. Vendors who only share executive summaries or marketing materials are signalling that detailed documentation would reveal compliance gaps.

3. Engage your security and compliance teams in vendor evaluation from the start. Compliance audit should be parallel to functional evaluation, not sequential. Security and compliance teams need time to review documentation, verify claims, and identify gaps. Engaging these teams after vendor selection produces decisions that may need to be reversed when compliance review surfaces issues.

4. Verify claims against architectural documentation. Vendor compliance claims should align with actual architecture. SOC 2 reports should describe the systems that serve your data. Data residency claims should align with infrastructure documentation. Vendors whose architecture documentation contradicts their compliance claims are signalling problems that procurement leverage should address.

5. Examine the vendor's compliance roadmap. Compliance is an ongoing operational discipline. Mature vendors have specific roadmaps for compliance evolution - upcoming certifications, regulatory tracking, security investments. Vendors who treat compliance as a one-time achievement are signalling that their compliance posture may degrade over time.

6. Engage customer references focused on compliance experience. Standard vendor references discuss platform satisfaction. Compliance-focused references discuss how the vendor handles audit support, security incidents, regulatory inquiries, and compliance documentation requests. The operational compliance experience varies dramatically across vendors.

7. Test the vendor's responsiveness to compliance questions. Vendor responsiveness to detailed compliance questions during procurement predicts vendor responsiveness during operational compliance work. Vendors who respond slowly or evasively to procurement compliance questions will likely respond similarly to compliance questions during the operational relationship.

8. Build contractual protection for compliance commitments. Compliance commitments should be in the MSA and DPA with specific remedies for non-compliance. Vendor failure to maintain compliance posture should have contractual consequences. Verbal or marketing-language commitments without contractual protection are operationally insufficient.

Where Skolarli's architecture fits this audit discipline

Skolarli's compliance and security posture is built around the four audit dimensions through specific architectural decisions:

1. SOC 2 Type II: Skolarli's SOC 2 Type II audit engagement is in progress; certification expected to complete in 2026. The architectural foundations supporting SOC 2 controls - access management, audit logging, change management, incident response - are operationally in place. Organisations requiring completed SOC 2 Type II should verify timeline expectations.
2. GDPR compliance: Skolarli operates as data processor with standard DPA, sub-processor disclosure, EU SCC arrangements where applicable, breach notification procedures, and explicit data subject rights handling. GDPR documentation is available under NDA for procurement evaluation.
3. DPDP Act 2023 compliance: Skolarli is built around DPDP Act 2023 requirements - designated DPO, notice and consent architecture aligned with DPDP, data principal rights handling, breach notification procedures, India-resident data residency. Skolarli is among the assessment platforms with the most explicit DPDP-specific compliance posture given the India-first product positioning.
4. Data residency: Skolarli's primary infrastructure is hosted in AWS Mumbai (ap-south-1), with explicit Indian data residency. AI processing for SkoAI features happens in-VPC through AWS Bedrock, maintaining data residency for AI-enabled assessment features. The architectural choice - AWS Mumbai with in-VPC AI processing - produces data residency posture that aligns with DPDP Act 2023 requirements and supports international customers requiring data residency commitments.

For organisations evaluating assessment platforms against the four compliance dimensions, the audit discipline above applies regardless of vendor. Skolarli's architecture supports detailed verification of compliance posture; the formal certifications continue to develop through ongoing audit engagement. Organisations requiring completed certifications should verify timeline expectations during procurement.

For organisations evaluating compliance audit programmes more broadly, the dimensions and verification disciplines are general enterprise procurement practice that holds regardless of vendor selection.

About this piece

This post is part of the Engineering Hiring at Scale series - an analytical series from Skolarli Akademy Research covering the technical and operational disciplines for engineering hiring at scale in the AI era.

Skolarli Akademy Research is the editorial arm of Skolarli Edulabs Pvt. Ltd., publishing analysis on learning, hiring, and assessment infrastructure. Findings are reviewed by Skolarli's founders and product leaders before publication.

Reviewed by Jayalekshmy Nair, Co-founder & CEO, Skolarli.