A hotel booking site stores names and email addresses of European Union residents and stores no payment card data. Which framework should the design be checked against?
Select an answer to reveal the explanation.
Short Explanation
You are storing people's names and email addresses, and those people live in the European Union. The privacy framework you should name for that personal data is GDPR. Card-brand rules apply when you keep payment cards, which this site does not, and naming the framework is not legal advice.
Full Explanation
The General Data Protection Regulation is the European Union framework for protecting personal data, including names and email addresses of people in the Union. A booking site that stores those details and does not store payment cards is being asked which framework fits that data. The expected recognition is GDPR. This question tests whether you can tell the frameworks apart. It is not legal advice, and a real deployment still needs counsel for scope and duties. PCI DSS is the payment-card industry standard for systems that store, process, or transmit cardholder data. The stem says the site stores no payment cards, so the card-brand standard is the wrong framework to name as the one this design must follow for these records. A retention schedule says how long the hotel keeps the names. It is an operations rule, not the privacy framework that covers people in the European Union. PCI DSS remains the card-brand standard, and the stem stores no card data, so applying it because the site stores names confuses a customer record with a card record. Exam caveat: a site can fall under more than one framework if it later adds card payments. With the facts given, the personal data of European Union residents is the GDPR fact, and the absence of card data is what sets PCI DSS aside. Operational check: inventory the booking database fields, confirm they are names and email addresses with no card data, and map that store to the organization's GDPR controls.