Ajob is an action that Sensitive Data Protection runs to either scan content forsensitive data or calculate the risk of re-identification.Sensitive Data Protection creates and runs a job resource whenever you tell it toinspect your data.

There are currently two types of Sensitive Data Protection jobs:

• Inspection jobs inspect your content for sensitive data according to yourcriteria and generate summary reports of where and what type of sensitivedata exists.
• Risk analysis jobs analyze de-identified data and return metrics about thelikelihood that the data can be re-identified.

You can schedule when Sensitive Data Protection runs jobs by creatingjobtriggers. A job trigger is an event that automates the creation ofSensitive Data Protection jobs to scan Google Cloud storage repositories,including Cloud Storage buckets, BigQuery tables, andDatastore kinds.

Job triggers enable you to schedule scan jobs by setting intervals at whicheach trigger goes off. They can be configured to look for new findings sincethe last scan run to help monitor changes or additions to content, or togenerate up-to-date findings reports. Scheduled triggers run on an intervalthat you set, from 1 day to 60 days.

Note: Prematurely canceling an operation midway through a job still incurs costs for the portion of the job that was completed. For more information about billing, seeSensitive Data Protection pricing.

Next steps

More information about how to create, edit, and run jobs and job triggers inthe following topics:

• Creating Sensitive Data Protection inspection jobs and jobtriggers
• Measuring re-identification and disclosure risk(Covers risk analysis jobs.)

In addition, the following quickstart is available:

• Quickstart creating a Sensitive Data Protection jobtrigger

TheJobTrigger object

A job trigger is represented in the DLP API by theJobTriggerobject.

Job trigger configuration fields

EachJobTrigger contains several configuration fields, including:

• The trigger's name and display name, and a description.
• A collection ofTriggerobjects, each of which contains aScheduleobject, which defines the scan recurrence in seconds.
• AnInspectJobConfigobject, which contains the configuration information for the triggered job.
• AStatusenumeration, which indicates whether the trigger is currently active.
• Timestamp fields representing creation, update, and last run times.
• A collection ofError objects, if anywere encountered when the trigger was activated.

Job trigger methods

EachJobTrigger object also includes several built-in methods. Using thesemethods you can:

• Create a new job trigger:projects.jobTriggers.create
• Update an existing job trigger:projects.jobTriggers.patch
• Delete an existing job trigger:projects.jobTriggers.delete
• Retrieve an existing job trigger, including its configuration and status:projects.jobTriggers.get
• List all existing job triggers:projects.jobTriggers.list

Job latency

There are no service level objectives (SLO) guaranteed for jobs and jobtriggers. Latency is affected by several factors, including the amount of datato scan, the storage repository being scanned, the type and number of infoTypesyou are scanning for, the region where the job is processed, and the computingresources available in that region. Therefore, the latency of inspection jobscan't be determined in advance.

To help reduce job latency, you can try the following:

• Ifsampling is availablefor your job or job trigger, enable it.

• Avoid enabling infoTypes that you don't need. Although the following areuseful in certain scenarios, these infoTypes can make requests run much moreslowly than requests that don't include them:

  • PERSON_NAME
  • FEMALE_NAME
  • MALE_NAME
  • FIRST_NAME
  • LAST_NAME
  • DATE_OF_BIRTH
  • LOCATION
  • STREET_ADDRESS
  • ORGANIZATION_NAME

• Always specify infoTypes explicitly. Do not use an empty infoTypes list.

• If possible, use a different processing region.

If you're still having latency issues with jobs after trying these techniques,consider usingcontent.inspect orcontent.deidentifyrequests instead of jobs. These methods are covered under the Service LevelAgreement. For more information, seeSensitive Data Protection Service LevelAgreement.

Limit scans to only new content

You can configure your job trigger to automatically set the timespan date forfiles stored inCloud Storage orBigQuery. When you set theTimespanConfigobject to auto-populate, Sensitive Data Protection only scans data that wasadded or modified since the trigger last ran:

...  timespan_config {        enable_auto_population_of_timespan_config: true      }...

For BigQuery inspection, only rows that are at least three hours oldare included in the scan. See theknownissue related to thisoperation.

Trigger jobs at file upload

In addition to the support for job triggers—which is built intoSensitive Data Protection—Google Cloud also has a variety of othercomponents that you can use to integrate or trigger Sensitive Data Protectionjobs. For example, you can useCloud Run functions totrigger a Sensitive Data Protection scan every time a file is uploaded toCloud Storage.

For information about how to set up this operation, seeAutomating theclassification of data uploaded toCloud Storage.