Can you mask other objects like Contact and Account or custom objects?
Yes! You simply need to add these objects to Blackthorn Compliance configuration. Follow these helpful steps.
Can you mask other Personally Identifiable Information (PII) data like social security numbers, driver's licenses, and IP addresses?
Yes! You simply need to create your own PII patterns in the Compliance configuration. Follow these helpful steps.
Can you mask mixed PII data that has a combination of letters and numbers?
Yes! Compliance supports matching mixed data types that include alpha, numeric, and special characters.
Can you unmask data if you need to still see the underlying information?
Masking is a permanent alteration of the data. That means - the underlying data is not accessible and therefore not editable, viewable, or searchable. However, you can still do two things:
- Partial Masking - you can mask everything but the last 4 characters so you can still verify SSNs, etc
- Report PII & Mask Later - you can set Compliance to "flag" the records that are detected with PII, and then automatically mask them later either with a scheduled mass update after your team has verified the information, or mask individual records from a report generated by Compliance.
I'm testing Compliance, and it's not masking my credit card. What's going on?
See My Credit Card Didn't Get Masked! for more details.
If our configuration is set to mask all but the last 4 characters, will this pattern continue to be detected in audits? For example, if we receive an attachment with this pattern, will it be caught in an audit? If so, do we have to modify the detection pattern?
Audits work the same as detecting new records. If you have configuration set to "Last4" then during audits you will also mask all but the last 4 characters.
Creating Detection Patterns: The user guide indicates that we must use Java Regular Expression – do you have any documentation on this?
Yes, Regular Expressions are powerful but complicated.
False Positives: Does flagging False Positives prevent similar records from being caught in audits, or is this just used for Crowdsourcing? Is turning off detection for that particular pattern or creating a negative pattern the only way to control false positives?
It is only used for crowdsourcing information, and will show up in the Analytics tab. We have a whole help site section about mitigating false positives, but the main method is negative patterns. Also, if you don't receive any Instapayment credit cards, for example, then patterns like this are worth turning off to avoid any accidental false positives.
Is deleting Logs the only way to remove them from the system after we have masked or deleted the related record? Is there a best practice for when to delete logs?
The best practice here depends on whether you care about the Analytics or not. The Reports & Dashboard are based on the Logs. If you delete them, the Analytics will be 0. If you do not want to use Analytics, many customers use a Dataloading tool to mass delete the Logs to conserve data storage space. We do have a script to mass-delete the Logs, but it might be better to use a tool for the job.
There is some confusion over relating a Log to a record. Does the Log always have a link to the related record?
The PCIFY Logs will always have a related record in either of the following scenarios:
- Records are updated (i.e. Before Update).
- You ran an Audit.
- Compliance detected PII in Attachments or ContentVersion.
Attachment and ContentVersion logs give you the link to the actual ContentVersion record and the parent Case. Cases don't need a parent record, so the "Parent Link" field will be blank.
Compliance Triggers are Before Insert and Before Update by default. This means that when the Email Message or Case is created, the ID of the record does not exist yet Before Insert, and therefore there will be no related ID in the PCIFY Log. You can disable our default Compliance Triggers and write your own, but this requires thorough knowledge of Apex coding.
Are emails containing logos and signatures scanned and counted against our SecureAttachment API usage?
Images included in the body of the email message are only included as API calls if they end up in the Attachments related list on the Case, as either attachment or content version records.
Is detection for ContentVersion based on the date/timestamp of the attachment? For instance, if I wanted to isolate a particular grouping of attachments, would I run an audit pointed to that specific time frame?
The Audit Start Date & End Dates are based on the CreatedDate of the record. So if you're auditing ContentVersion, the date range would find all ContentVersion records created between those dates. (Please note that you can change the default Audit date range field to any other DateTime field (such as LastModifiedDate) by changing the AuditDateField in the Manager Custom Metadata Type.)
I know that Attachment is the old Salesforce object and ContentVersion is the new one. When running an audit, should we use only Object=ContentVersion or can we use Object=Attachment?
This depends on your production org. It is possible for you to have both types of records. There is a chance that you still have old Attachments which could have PII, even if you currently use ContentVersion. Here is a useful link which explains the difference.
Are the timestamps in the audit the same as our System date?
Yes, the "Timestamp" field on the Logs is the same as the System "CreatedDate" field.
Updated 3 months ago