Does GDPR apply to us if we're based outside the EU?

Yes, where you offer goods or services to individuals in the EU, or monitor their behavior — Art. 3(2)'s extraterritorial scope applies regardless of where your organization is established. Scope for your specific operations should be confirmed with counsel.

How does GDPR relate to India's DPDPA?

They share core concepts (lawful basis, individual rights, breach notification) but differ in mechanics — DPDPA has no DPIA requirement in the same form, uses Consent Managers, and has its own penalty structure. If both apply to you, map them together rather than assuming one covers the other.

Do we need to appoint an EU representative if we have no EU establishment?

Often yes, under Art. 27, if you're subject to GDPR's extraterritorial scope and don't otherwise qualify for an exemption — this is commonly missed by non-EU organizations that know about the Regulation but not this specific obligation.

GDPR Readiness Checklist

1.1A named owner is accountable for GDPR compliance, with a documented reporting line to leadershipArt. 5(2)Accountability (Art. 5(2)) means being able to demonstrate compliance, not just claim it.
How to verify this →
Test procedureAsk who owns GDPR compliance day-to-day and confirm it matches an organization chart or RACI, not just a verbal answer.
Practical example / evidenceRACI matrix or org chart naming the privacy owner and their reporting line
1.2A data protection policy suite exists, approved and reviewed on a defined cadenceArt. 24Covers the full suite — data protection policy, retention, breach response, rights-handling, vendor management.
How to verify this →
Test procedureCheck approval dates and the review cadence against the policy's own stated review interval.
Practical example / evidenceApproved policy suite with version history and review dates
1.3A register of processing activities is actively maintained, not a one-time exerciseHigh riskArt. 30A RoPA built once for an audit and never touched again is the single most common accountability gap.
How to verify this →
Test procedureCheck the RoPA's last-updated date against a recent change to systems or vendors.
Practical example / evidenceRecords of Processing Activities (RoPA) with a visible update history
1.4Compliance evidence (DPIAs, processor agreements, training logs, incident records) is retained and retrievableWhen a regulator asks, you need to produce this quickly — not reconstruct it.
How to verify this →
Test procedurePick one processing activity and ask for its full evidence trail on the spot.
Practical example / evidenceEvidence repository or shared drive structure mapped to each processing activity
1.5GDPR obligations are mapped against other applicable regimes (DPDPA, CCPA, sector rules) in one registerOperating in multiple jurisdictions without a single register leads to duplicated or contradicted controls.
How to verify this →
Test procedureReview the cross-regime mapping document for overlap and conflicts between GDPR and other applicable laws.
Practical example / evidenceCross-regime obligations register or mapping matrix
1.6Data protection is on a standing agenda for a leadership or risk committeeEvidence that privacy risk reaches people with budget authority, not just the privacy team.
How to verify this →
Test procedureReview committee minutes for recurring data-protection agenda items.
Practical example / evidenceCommittee charter and minutes showing recurring privacy agenda items
1.7Exceptions and risk acceptances against GDPR controls are logged, approved and time-boundLow riskAn undocumented exception is indistinguishable from a gap when a regulator reviews it.
How to verify this →
Test procedureSample the exceptions log and confirm each entry has an approver, rationale and review date.
Practical example / evidenceExceptions/risk-acceptance log with approver and expiry date

Stage 1 of 11

2.1Every processing activity has a documented lawful basis under Article 6High riskArt. 6One of six bases: consent, contract, legal obligation, vital interests, public task or legitimate interests.
How to verify this →
Test procedureSample 5 processing activities from the RoPA and confirm each cites a specific Art. 6 basis, not a blanket default.
Practical example / evidenceRoPA entries showing lawful basis per processing activity
2.2Legitimate interests relied upon are backed by a documented balancing testArt. 6(1)(f)"Legitimate interests" without a written balancing test is the basis regulators challenge most often.
How to verify this →
Test procedureFor each activity relying on legitimate interests, check for a dated balancing-test document.
Practical example / evidenceLegitimate Interests Assessment (LIA) per relevant processing activity
2.3Special category data (health, biometric, religious, etc.) has a valid Article 9 condition on top of its Article 6 basisHigh riskArt. 9Special category data needs both an Art. 6 basis and a separate Art. 9 condition — a frequently missed second step.
How to verify this →
Test procedureFor any special category data in the RoPA, confirm both an Art. 6 basis and an Art. 9 condition are recorded.
Practical example / evidenceRoPA entries showing both Art. 6 basis and Art. 9 condition where applicable
2.4The RoPA records purpose, categories of data, recipients, third-country transfers and retention period per activityArt. 30A RoPA missing retention periods or recipients isn't audit-ready even if it technically exists.
How to verify this →
Test procedureCheck the RoPA template fields against the full list Art. 30 requires.
Practical example / evidenceRoPA template/export showing all required fields populated
2.5Processing of children's data (where applicable) has age-verification and parental-consent mechanismsArt. 8Relevant wherever your product could reasonably be used by minors.
How to verify this →
Test procedureReview the age-gate/consent flow for any product surface reachable by minors.
Practical example / evidenceAge-verification and parental-consent flow documentation
2.6Purpose limitation is enforced — data isn't reused for a new purpose without re-assessing the lawful basisA common drift: data collected for one purpose quietly gets used for another (e.g. analytics data used for marketing).
How to verify this →
Test procedurePick a dataset and trace every system that consumes it against its originally stated purpose.
Practical example / evidenceData-flow map showing purpose per downstream use
2.7Data minimization is applied — only data genuinely needed for the stated purpose is collectedArt. 5(1)(c)Over-collection increases both breach exposure and your Art. 5(1)(c) compliance burden.
How to verify this →
Test procedureReview a sample intake form or API payload against the purpose it serves for unnecessary fields.
Practical example / evidenceData minimization review for at least one major collection point
2.8Retention schedules are defined per data category and enforced technically, not just on paperMedium riskA written retention policy that isn't enforced by a deletion job is not evidence of compliance.
How to verify this →
Test procedurePick a data category past its stated retention period and confirm it was actually deleted or justified as still needed.
Practical example / evidenceRetention schedule plus evidence of an automated or scheduled deletion process

Stage 2 of 11

3.1Consent capture is freely given, specific, informed and unambiguous — no pre-ticked boxesHigh riskArt. 7Pre-ticked boxes, bundled consent and silence all fail the GDPR consent standard.
How to verify this →
Test procedureWalk through the actual consent UI/flow and check for pre-ticked boxes or bundled permissions.
Practical example / evidenceScreenshots or recording of the live consent flow
3.2Consent is as easy to withdraw as it was to give, with no penalty for withdrawingArt. 7(3)A consent flow with a one-click opt-in and a multi-step opt-out fails Art. 7(3).
How to verify this →
Test procedureAttempt to withdraw consent through the actual product and time/step-count it against the opt-in flow.
Practical example / evidenceWithdrawal flow walkthrough, compared step-for-step with the opt-in flow
3.3Consent records (who, when, what version of notice, what was agreed) are retained as proofYou need to be able to prove consent was given, not just that a checkbox exists today.
How to verify this →
Test procedurePull a consent record for a specific individual and confirm it has a timestamp and notice version.
Practical example / evidenceConsent log/database with timestamp and notice-version fields
3.4Privacy notices disclose identity/contact details, purposes, lawful basis, recipients, retention and rightsArt. 13-14Articles 13–14 specify an exact list of disclosures — a generic privacy policy often misses several.
How to verify this →
Test procedureCheck the live privacy notice against the full Art. 13/14 disclosure checklist line by line.
Practical example / evidenceCurrent privacy notice mapped against the Art. 13/14 disclosure list
3.5Notices are presented at the point of collection, not buried in a separate legal page onlyLayered/just-in-time notices at the collection point are expected practice, not just a nice-to-have.
How to verify this →
Test procedureCheck whether a notice or link to one appears at the actual point data is collected (form, API, SDK).
Practical example / evidenceScreenshot of the notice or notice link at the point of collection
3.6Privacy notices are reviewed and updated whenever processing purposes or recipients changeA notice that doesn't match current data flows is a transparency gap even if it was accurate once.
How to verify this →
Test procedureCompare the current notice's stated recipients/purposes against the current RoPA.
Practical example / evidenceChange log showing the notice was updated alongside a processing change
3.7Cookie and tracking consent is layered — strictly necessary cookies load before consent, others waitMedium riskNon-essential trackers firing before consent is one of the most commonly enforced GDPR/ePrivacy gaps.
How to verify this →
Test procedureLoad the site with a clean browser profile and inspect network requests before any consent action.
Practical example / evidenceNetwork trace showing non-essential cookies/trackers blocked pre-consent

Stage 3 of 11

4.1A documented, tested workflow exists for access requests, completed within one monthHigh riskArt. 15The one-month clock (extendable once, by two months, for complex requests) starts on receipt — not on verification.
How to verify this →
Test procedureRun a test subject access request through the real intake channel and time the full response.
Practical example / evidenceSAR workflow documentation plus a timed test-run record
4.2Identity verification for rights requests is proportionate — not so strict it becomes a barrierOver-verification (e.g. demanding a notarized ID for a simple access request) is itself a compliance risk.
How to verify this →
Test procedureReview the verification steps required for a standard access request against the sensitivity of the data involved.
Practical example / evidenceIdentity-verification procedure for rights requests
4.3Rectification, erasure, restriction, portability and objection each have a working, documented processArt. 16-21Access requests get the most attention; the other five rights are where gaps usually hide.
How to verify this →
Test procedurePick one of the less-common rights (e.g. restriction or portability) and walk through its actual workflow.
Practical example / evidenceDocumented workflow for each of the six rights, not just access
4.4Erasure requests propagate to backups, logs and any processors holding the same dataMedium riskArt. 17Deleting from the primary database while backups and vendor copies retain the data is a common erasure gap.
How to verify this →
Test procedureTrace an erasure request's downstream reach into at least one backup system and one processor.
Practical example / evidenceErasure-propagation procedure covering backups and processors
4.5Data portability exports are provided in a structured, commonly used, machine-readable formatArt. 20A PDF export does not satisfy Art. 20 — it has to be genuinely machine-readable (e.g. JSON, CSV).
How to verify this →
Test procedureGenerate a real portability export and confirm the format a receiving system could actually ingest.
Practical example / evidenceSample portability export in a machine-readable format
4.6Objections to processing (including direct marketing) are honored immediately, without a justification testArt. 21An objection to direct marketing must stop processing immediately — no balancing test applies there.
How to verify this →
Test procedureSubmit a test objection to marketing processing and confirm it stops without delay or pushback.
Practical example / evidenceMarketing-objection handling procedure and a test-run record
4.7Automated decision-making with legal or similarly significant effects offers a path to human reviewHigh riskArt. 22Purely automated decisions (e.g. automated credit or hiring decisions) trigger Art. 22 rights to contest and get human review.
How to verify this →
Test procedureFor any automated-decision system with significant effects, confirm a human-review request path exists and is reachable.
Practical example / evidenceAutomated-decision inventory with the human-review path documented
4.8Rights-request volumes and response times are tracked and reported, not just handled ad hocTracking turns rights-handling from a reactive scramble into a measurable, improvable process.
How to verify this →
Test procedureAsk for the rights-request log/dashboard and check it has volume and response-time metrics.
Practical example / evidenceRights-request tracking log or dashboard

Stage 4 of 11

5.1New products or features go through a privacy review before build starts, not before launchArt. 25(1)Reviewing privacy at launch is too late to influence architecture — Art. 25 expects "by design," not "by patch."
How to verify this →
Test procedureCheck the product development process for a privacy-review gate and its position in the timeline.
Practical example / evidenceDevelopment process documentation showing the privacy-review gate's position
5.2Default settings are the most privacy-protective option, with no action needed from the userMedium riskArt. 25(2)Art. 25(2) requires privacy-protective defaults — opt-in for sharing, not opt-out.
How to verify this →
Test procedureCreate a fresh account/profile and inspect the default state of every privacy-relevant setting.
Practical example / evidenceDefault-settings audit for a newly created account
5.3Pseudonymization or anonymization is applied wherever the purpose doesn't require identifiable dataUsing identifiable data where pseudonymized data would do increases unnecessary risk and regulatory exposure.
How to verify this →
Test procedureReview at least one analytics or reporting pipeline for whether identifiable fields could be pseudonymized.
Practical example / evidencePseudonymization/anonymization review for a sampled data pipeline
5.4Data minimization is a named checkpoint in the product/engineering review processTreating minimization as a formal checkpoint (not a hoped-for habit) is what makes it durable across team changes.
How to verify this →
Test procedureCheck a recent design or architecture review document for a data-minimization checkpoint.
Practical example / evidenceDesign review template or checklist with a minimization checkpoint
5.5Access to personal data is restricted by role, on a need-to-know basis, by defaultMedium riskBroad default access ("everyone in engineering can query prod") undermines by-design privacy regardless of policy wording.
How to verify this →
Test procedureReview access-control configuration for at least one system holding personal data against actual job need.
Practical example / evidenceAccess-control matrix or RBAC configuration for a sampled system

Stage 5 of 11

6.1A documented trigger list defines when a DPIA is required (large-scale special category data, systematic monitoring, automated decisions)Art. 35(3)Without a trigger list, DPIA decisions default to whoever happens to remember — inconsistent and unauditable.
How to verify this →
Test procedureReview the DPIA-trigger criteria document against Art. 35's examples and your own high-risk processing.
Practical example / evidenceDPIA trigger-criteria document
6.2DPIAs are completed and signed off before the relevant processing begins, not retrofitted after launchHigh riskA DPIA dated after go-live defeats its purpose and signals process failure to a regulator.
How to verify this →
Test procedureCheck DPIA completion dates against the go-live dates of the processing they cover.
Practical example / evidenceDPIA sign-off dates compared against processing/launch dates
6.3DPIAs assess necessity, proportionality and risks to individuals, with documented mitigating measuresArt. 35(7)A DPIA that only describes the processing without assessing risk and mitigation isn't a DPIA.
How to verify this →
Test procedureReview a completed DPIA for a necessity/proportionality assessment and a mitigation section, not just a description.
Practical example / evidenceCompleted DPIA with explicit risk and mitigation sections
6.4Where residual risk remains high after mitigation, prior consultation with the supervisory authority occursArt. 36Art. 36 prior consultation is rare but mandatory when mitigation can't bring risk to an acceptable level.
How to verify this →
Test procedureCheck whether any DPIA concluded high residual risk, and if so, confirm a consultation record exists.
Practical example / evidenceSupervisory authority consultation record, if applicable
6.5DPIAs are revisited when the nature, scope or risk of the processing changes materiallyA DPIA is a living assessment tied to the processing, not a one-time form filed and forgotten.
How to verify this →
Test procedureCheck DPIA revision history against any material change to the processing it covers.
Practical example / evidenceDPIA version history showing re-assessment after material change

Stage 6 of 11

7.1DPO-mandatory status is assessed against Art. 37's criteria, not assumed either wayArt. 37Mandatory for public authorities, large-scale systematic monitoring, or large-scale special category processing — a documented assessment avoids guessing.
How to verify this →
Test procedureReview the documented assessment of whether a DPO is legally required for your organization.
Practical example / evidenceDPO-requirement assessment document
7.2Where a DPO is appointed (mandatory or voluntary), they report to the highest level of managementArt. 38(3)A DPO buried several layers below leadership, with no direct reporting line, fails Art. 38's independence requirement.
How to verify this →
Test procedureCheck the DPO's actual reporting line against the org chart.
Practical example / evidenceOrg chart showing the DPO's reporting line
7.3The DPO (or equivalent privacy lead) operates without being instructed on how to carry out their tasksIndependence is a specific, testable requirement — not just a job title.
How to verify this →
Test procedureInterview the DPO/privacy lead about any instance of being directed on a compliance conclusion.
Practical example / evidenceWritten confirmation of the DPO's independence in their role charter
7.4The DPO's contact details are published and communicated to the supervisory authorityArt. 37(7)A DPO individuals and regulators can't actually reach doesn't satisfy Art. 37(7).
How to verify this →
Test procedureCheck the privacy notice and any regulator filing for current, correct DPO contact details.
Practical example / evidencePublished DPO contact details in the privacy notice
7.5Where no DPO is required, a named privacy lead still owns day-to-day compliance decisionsEven without a legal DPO requirement, someone needs clear ownership — this is a recommended practice, not an Art. 37 obligation.
How to verify this →
Test procedureConfirm there is a single named individual accountable for privacy decisions day-to-day.
Practical example / evidenceRole description or RACI naming the privacy lead

Stage 7 of 11

8.1Every vendor processing personal data on your behalf is inventoriedHigh riskVendor lists are almost always longer than DPA lists — this is the step that surfaces the gap.
How to verify this →
Test procedureCompare your full vendor/subprocessor inventory against your list of signed DPAs.
Practical example / evidenceVendor inventory cross-referenced against signed DPAs
8.2A Data Processing Agreement covering Art. 28(3)'s required terms is in place before data sharing beginsArt. 28(3)Required terms: purpose and duration, nature of processing, data types, controller instructions, confidentiality, security, subprocessor rules, audit rights, return/deletion at end of contract.
How to verify this →
Test procedureReview a sample DPA against the full Art. 28(3) required-terms list.
Practical example / evidenceSample DPA checked against Art. 28(3) requirements
8.3Sub-processor engagement requires either prior specific or general authorization, documented either wayA processor engaging a sub-processor without your authorization on record is a contractual and GDPR gap.
How to verify this →
Test procedureCheck the DPA's sub-processor clause and confirm it matches the authorization approach actually used.
Practical example / evidenceDPA sub-processor clause and current sub-processor list
8.4Processors are only permitted to act on documented instructions from the controllerA processor acting outside documented instructions risks becoming a joint or independent controller — with its own compliance exposure for you.
How to verify this →
Test procedureReview the DPA's instructions clause and confirm actual processing matches documented instructions.
Practical example / evidenceDPA instructions clause compared against actual processing activity
8.5Audit rights over processors are genuinely exercisable, not just contractually presentAn audit clause no one has ever used, against a processor that would refuse access, isn't real assurance.
How to verify this →
Test procedureAsk whether any processor audit (desk-based or on-site) has actually been performed in the last 12 months.
Practical example / evidenceRecord of a processor audit, questionnaire or compliance review
8.6End-of-contract data return or deletion is specified and verified, not just assumedConfirming a former vendor actually deleted your data is a step organizations frequently skip.
How to verify this →
Test procedurePick a terminated vendor relationship and look for evidence of data return or deletion confirmation.
Practical example / evidenceDeletion/return confirmation from at least one terminated vendor

Stage 8 of 11

9.1A risk-based security assessment has informed which technical and organizational measures are in placeArt. 32(1)Art. 32 measures must be "appropriate to the risk" — which requires having assessed that risk first.
How to verify this →
Test procedureReview the security risk assessment that informed the current control set.
Practical example / evidenceSecurity risk assessment document referencing personal data processing
9.2Personal data is encrypted at rest and in transit wherever technically feasibleHigh riskEncryption is explicitly named in Art. 32 as an example measure, and it's the one regulators check first after a breach.
How to verify this →
Test procedureCheck encryption configuration for at least one production datastore and one data-in-transit path.
Practical example / evidenceEncryption configuration evidence (at-rest and in-transit)
9.3Confidentiality, integrity, availability and resilience of processing systems are actively tested, not assumedArt. 32(1)(b) names all four properties — availability/resilience testing is the one most often skipped.
How to verify this →
Test procedureReview evidence of a recent resilience or disaster-recovery test, not just a backup policy document.
Practical example / evidenceRecent DR/resilience test report
9.4The ability to restore availability and access to personal data after an incident is testedArt. 32(1)(c) requires a tested restoration capability — an untested backup is not evidence of this.
How to verify this →
Test procedureAsk for the most recent backup-restoration test and its result.
Practical example / evidenceBackup restoration test record and result
9.5A process for regularly testing and evaluating the effectiveness of security measures existsArt. 32(1)(d) — penetration tests, vulnerability scans or control-effectiveness reviews on a defined cadence.
How to verify this →
Test procedureCheck the cadence and most recent date of security testing against personal-data-processing systems.
Practical example / evidenceSecurity testing schedule and most recent test report
9.6Access controls limit personal data access to individuals who need it for their roleMedium riskPairs with privacy-by-design's access controls, but here assessed specifically as a security measure.
How to verify this →
Test procedureSample access logs/permissions for a system holding personal data against job roles.
Practical example / evidenceAccess control review for a sampled personal-data system

Stage 9 of 11

10.1Every transfer of personal data outside the EU/EEA is identified and mapped to a specific transfer mechanismHigh riskCh. V"We use a US cloud provider" is a transfer that needs its own documented mechanism, not an assumption it's covered elsewhere.
How to verify this →
Test procedureReview the RoPA or data-flow map for every third-country transfer and its stated legal mechanism.
Practical example / evidenceTransfer inventory mapped to a mechanism per transfer
10.2Standard Contractual Clauses (or another approved mechanism) are in place for each relevant transferSCCs are the most common mechanism; adequacy decisions and BCRs are the alternatives where applicable.
How to verify this →
Test procedurePull the signed SCCs (or equivalent) for a sample transfer and confirm the correct module is used.
Practical example / evidenceSigned SCCs or equivalent transfer mechanism per transfer
10.3A Transfer Impact Assessment has been completed for transfers relying on SCCsSchrems IIPost-Schrems II, SCCs alone aren't sufficient — the destination country's laws and practices must be assessed.
How to verify this →
Test procedureReview the TIA for a sampled transfer, checking it assesses the destination country's legal regime.
Practical example / evidenceTransfer Impact Assessment for at least one SCC-based transfer
10.4Supplementary measures (technical, contractual or organizational) are applied where a TIA identifies gapsWhere a TIA finds the destination country's protections insufficient, SCCs alone don't close the gap — supplementary measures do.
How to verify this →
Test procedureFor any TIA that identified a gap, confirm a corresponding supplementary measure is documented.
Practical example / evidenceSupplementary measures documentation tied to a TIA finding
10.5Reliance on the EU-US Data Privacy Framework (where used) is monitored for its current legal statusThe DPF remains subject to ongoing legal challenge — relying on it without monitoring its status is a forward-looking risk.
How to verify this →
Test procedureConfirm someone is tracking the DPF's legal status if your organization relies on it for any transfer.
Practical example / evidenceRecord of DPF status monitoring, if the DPF is relied upon

Stage 10 of 11

11.1A documented incident response plan defines how a personal data breach is detected, triaged and escalatedArt. 33Without a defined trigger for "this might be a personal data breach," the 72-hour clock can start late without anyone noticing.
How to verify this →
Test procedureReview the incident response plan for a specific personal-data-breach triage and escalation path.
Practical example / evidenceIncident response plan with a personal-data-breach escalation path
11.2Supervisory authority notification, where required, happens within 72 hours of becoming awareHigh riskArt. 33(1)"Becoming aware" — not "confirming" — starts the clock; initial notifications can be provided in phases.
How to verify this →
Test procedureReview a tabletop exercise or real incident timeline against the 72-hour notification requirement.
Practical example / evidenceIncident timeline (real or tabletop) showing notification within 72 hours
11.3Notifications to the supervisory authority include nature of the breach, categories and approximate numbers affected, likely consequences and measures takenArt. 33(3) specifies exact content requirements — a vague notification can itself draw regulatory scrutiny.
How to verify this →
Test procedureReview a breach-notification template against the Art. 33(3) required-content list.
Practical example / evidenceBreach notification template mapped to Art. 33(3)
11.4Affected individuals are notified without undue delay when a breach poses a high risk to their rights and freedomsArt. 34Individual notification has a higher risk threshold than regulator notification, but is required whenever that threshold is met.
How to verify this →
Test procedureReview the criteria used to decide whether individual notification is triggered for a given incident.
Practical example / evidenceIndividual-notification trigger criteria and a notification template
11.5A breach register logs every incident assessed, including ones concluded not to meet the notification thresholdRegulators can ask for the full register, not just notified breaches — under-logging is itself a finding.
How to verify this →
Test procedureReview the breach register for incidents that were assessed and concluded not reportable, with rationale.
Practical example / evidenceBreach register including non-notified, assessed incidents
11.6Processors are contractually required to notify the controller of a breach without undue delayA processor's breach is still your notification obligation — the DPA needs to guarantee you hear about it fast.
How to verify this →
Test procedureCheck the DPA's breach-notification clause for a specific, short notification deadline from processor to controller.
Practical example / evidenceDPA clause requiring prompt processor-to-controller breach notification

Stage 11 of 11

Empanelled as NITCON’s Technology Partner.

Free V-SeQuor Testing & Evaluation.

GDPR Readiness Checklist — every obligation, mapped to the Article that requires it.

Get your readiness score

Governance & accountability

Lawful basis & records of processing

Data subject rights

Privacy by design & by default

Data protection impact assessments

Data Protection Officer & governance structure

Processor & vendor contracts

Security of processing

International data transfers

Breach detection & notification

Frequently asked questions

Related reading