PCI-DSS compliance profile

vulkro-sf antipatterns --compliance=pci adds payment-card field names to the PII checks, so card data written to logs or plain audit fields is flagged.

vulkro-sf antipatterns . --compliance=pci
vulkro-sf antipatterns . --compliance=hipaa,pci
vulkro-sf compliance report --framework pci ./force-app

The profile widens these checks (see antipatterns):

Rule	What it finds
AP-015	Card fields written to System.debug(...).
AP-016	JSON.serialize(record) in a log, which includes every field on the record.
AP-017	A card field copied into a non-encrypted custom audit or log field.

Use hipaa,pci together for records that hold both PHI and card data.

Field classes added

Pattern	Why it is PCI-relevant
CardNumber__c / PAN__c / CCNumber__c / CreditCardNumber__c / CCN__c	Primary Account Number. Storing the full PAN requires encryption and puts the org in scope.
CVV__c / CVC__c / CV2__c / CID__c / CardSecurityCode__c	Card-verification value. Requirement 3.2 forbids storing it after authorisation.
CardExpiry__c / CardExpiration__c / ExpirationDate__c	Expiration date. Stored with the PAN, it puts the record in scope.
CardholderName__c / CardHolder__c	Cardholder name. With the PAN, it is full cardholder data.
Track1__c / Track2__c / MagStripe__c	Magnetic-stripe data. Requirement 3.2 forbids storing it after authorisation.
RoutingNumber__c / ABA__c / IBAN__c / BankAccount__c / AchAccount__c / SwiftCode__c	Banking identifiers. Outside PCI-DSS itself but often stored alongside card data.

See also: HIPAA mapping, Compliance overview