A cloud administrator disables multi-factor authentication on systems holding citizen personal data to 'reduce friction.' How should this change be viewed under GDPR security expectations?
Select an answer to reveal the explanation.
Short Explanation
Turning off MFA to make login 'easier' is like unlocking the city vault because the key was annoying. Strong access control is part of the security package GDPR expects. Friction for attackers is a feature, not a bug, when citizen data is inside.
Full Explanation
Article 32 requires technical and organisational measures appropriate to the risk of processing. For systems holding citizen personal data, robust authentication—often including multi-factor authentication—is a common and expected control. Disabling MFA solely to “reduce friction” is a regression of those TOMs: it increases the likelihood of unauthorised access and must be justified against residual risk with compensating controls, not treated as a convenience entitlement for administrators.
Calling MFA optional cosmetics misreads Article 32’s risk-based substance; antivirus name-dropping in a policy appendix does not exhaust security duties. Disabling MFA does not improve GDPR compliance by maximising data-subject “ease of access”—end-user UX and privileged-system authentication are different problems. TOMs also do not freeze at go-live; material authentication changes require fresh evaluation of appropriateness.
Exam caveat: operational convenience is not an Article 32 derogation. Operational check: require joint security and privacy approval before weakening MFA, document residual risk, compensating controls, and monitoring, and re-test privileged access paths to citizen datasets. Municipal platforms that store resident records should preserve strong authentication as a baseline public-service control, explaining in the change record why “friction reduction” was rejected as an insufficient reason to unlock the city’s digital vault.