Payment card or bank account details
Card numbers are in scope for PCI DSS and bank details are sensitive PI under CPRA. A CRM is not a card data environment.
Keep it how long
The gap we see most
Card or account numbers typed into a notes or custom field to take payment over the phone.
What holding it is evidence for
Requirement text and artefacts stated in our own words from the published standards.
Payment details in a CRM field GDPR Art.32 · CCPA/CPRA §1798.100(e) · ISO/IEC 27701:2019 6.7.1
GDPR Art.32 Security of processingImplement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk of varying likelihood and severity for the rig...
CCPA/CPRA §1798.100(e) Maintain reasonable security for personal informationA business that collects personal information must run security procedures and practices suited to the nature of the data, so that it is not accessed, destroyed, used, altered or disclosed without authority or unlawfully, as section 1798.81.5 requires. A breach of nonencrypted or nonredacted data ca...
ISO/IEC 27701:2019 6.7.1 Cryptographic controlsThe policy on the use of cryptographic controls must take account of jurisdictions that require cryptography for particular categories of personal data such as health data or national identifiers, the organization must tell the customer in what circumstances it applies cryptography to the personal d...
Do this for your whole CRM
Paste your field list and get this classification for every field at once, with the record of processing per object, the gaps, and the controls the register is evidence for. No account for the first run.
Build my field registerGovernment identifier (passport, national ID, SSN, tax number) · Password, PIN or security answer