Dataverse Column Security and Auditing

Lock down PII fields with column-level security and audit trails in Dataverse.

Introduction

30 Second Summary

When organizations handle sensitive personnel data like emergency contacts, every access needs to be controlled and every change needs to be logged. Government agencies operate under strict frameworks that demand proof of who saw what and when.

In this project, you will add column-level security and auditing to your existing emergency deployment app in Dataverse. You'll configure masking rules that show partial values to unauthorized users and enable an immutable audit trail that logs every data change.

What You'll Build

A security-hardened data layer for your emergency deployment app with PII protection, custom masking rules, and full environment-to-column auditing.

By the end of this project, you'll have:

Emergency contact columns protected by column-level security with a custom regex masking rule that shows only partial phone numbers to unauthorized users.
Two column security profiles granting different access levels: masked read-only for field supervisors and full unmasked access for emergency coordinators.
Dataverse auditing enabled at environment, table, and column levels with a 365-day retention period creating an immutable change log.
Secret Mission: Build a NIST SP 800-53 AU compliance evidence matrix mapping your auditing configuration to government security control requirements.

Are there any prerequisites?

You need to have completed Project 1 (the emergency deployment Canvas App with a Dataverse deployment table in a Managed Environment). You also need the System Administrator role in your environment and access to the Microsoft 365 admin center to create users.

Set Up a Test User with Power Apps Premium Trial

To verify that your security controls actually work, you need a second user account that does not have administrator privileges. This "test user" will simulate a field supervisor accessing your deployment data.

In this step, you will create a new user in the Microsoft 365 admin center, assign them a free Power Apps Premium trial license, and add them to your Managed Environment with minimal permissions.

In this step, get ready to:

Create a test user account in the Microsoft 365 admin center.
Add the test user to your Managed Environment with the Basic User security role.
Verify the test user appears with the correct role and Enabled status.

Create a new user in the Microsoft 365 admin center

The Microsoft 365 admin center is where you manage user accounts and license assignments for your organization. You will create a user here and assign them a Power Apps Premium trial license, which is free for 30 days.

Open a new browser tab and navigate to admin.microsoft.com.
Sign in with the same administrator account you use for Power Platform.
In the left navigation menu, select Users, then select Active users.
Select Add a user at the top of the page.
Enter Field Tester as the display name.
Enter a username of your choice (for example, fieldtester).
Leave Automatically create a password selected.
Select Next to proceed to the license assignment screen.
On the Product licenses page, check the box next to Power Apps Premium (listed as a trial option).
Select Next through the remaining prompts, keeping defaults.
Select Finish adding to create the user.
Copy or note the temporary password shown on the confirmation screen. You will need it in Step 5 when you sign in as this user.

Why a Power Apps Premium trial?

Your environment is a Managed Environment, which requires users to have a Power Apps Premium license to run apps. The trial is free for 30 days and gives full premium capabilities to the test user.

After the trial expires, the license costs $20 per user per month. You can delete the test user in the Before You Go section to avoid any charges.

Don't see Power Apps Premium in the license list?

If you do not see a Power Apps Premium trial option, your tenant may not have trials enabled. Check with your tenant administrator or search for "Power Apps per user plan" in the license list.

help me find and assign a Power Apps Premium trial license to a new user

Add the test user to your Managed Environment

Creating the user in Microsoft 365 does not automatically give them access to your Power Platform environment. You need to explicitly add them and assign a security role.

Switch back to your Power Platform admin center browser tab.
In the left navigation, select Environments.
Select your Managed Environment from the list.
Select Settings in the top menu bar.
Expand Users + permissions and select Users.
Select Add user.
Enter the test user's email address (the username you just created) and select Add.
Select Manage security roles for the test user.
Check only the Basic User security role.
Select Save.

What is the Basic User role?

Basic User is a predefined Dataverse security role that provides minimum privileges. It lets the user access the environment and interact with core tables, but it does not grant administrative capabilities or access to secured columns.

User not appearing after adding?

It can take a few minutes for new users to propagate from Microsoft 365 to Power Platform. If the search returns no results, wait 2-3 minutes and try again.

help me troubleshoot why my new user is not appearing in the Power Platform environment

Verify the test user's role and status

On the Users list page in your environment settings, find the Field Tester user.
Confirm their Status shows Enabled.
Select the user to view their security roles. Confirm that only Basic User is assigned.
Note the user's full username (for example, fieldtester@yourdomain.onmicrosoft.com). You will need it in Step 5 when testing security controls.

Status shows Disabled?

If the user's status is Disabled, return to the Microsoft 365 admin center and ensure the account is not blocked from sign-in. Select the user, then check Block sign-in is turned off under their account settings.

help me fix a disabled user in Power Platform

Your test user is ready. Next up, you will add sensitive PII columns to your deployment table and lock them down with column-level security.

Add PII Columns and Enable Column Security

Your deployment table tracks operational data, but real emergency deployments also involve sensitive personnel information.

In this step, you will add two PII columns (emergency contact phone and email) to the deployment table and enable column-level security on them. Once secured, these columns will display as ******** for any user who has not been granted access through a column security profile.

In this step, get ready to:

Add emergency contact phone and email columns to your deployment table.
Enable column security on both new columns.
Add sample data to test masking against later.

Add two new columns to the deployment table

Emergency contact information is sensitive personal data that requires protection. You will create two dedicated columns to hold this data before locking them down.

Switch back to Power Apps (make.powerapps.com) where you are already signed in.
Confirm your environment is selected in the environment picker at the top right.
In the left navigation, select Tables.
Find and open your deployment table from Project 1.
Select Schema in the table navigation, then select Columns.
Select + New column to create the first column.
Enter Emergency Contact Phone as the Display name.
Set the Data type to Single line of text.
Set the Maximum character count to 20.
Select Save.

Now create the second column for email addresses.

Select + New column again.
Enter Emergency Contact Email as the Display name.
Set the Data type to Single line of text.
Set the Maximum character count to 100.
Select Save.

Both columns should now appear in your columns list under Schema.

Why two separate PII columns?

In government deployments, emergency contact phone and email are classified as personally identifiable information (PII). Storing them in dedicated columns lets you apply granular security controls to each one independently.

Later in this project, you will apply a masking rule to the phone column (showing partial digits) while keeping the email column fully hidden. This demonstrates both protection strategies in one table.

Don't see the + New column button?

Make sure you are inside the table view (not the Tables list). Select the table name to open it, then select Schema > Columns. The button appears in the command bar above the columns list.

help me find where to add columns to my Dataverse table

Enable column security on both columns

Adding a column does not protect it by default. You need to explicitly enable column security so that Dataverse enforces access restrictions on the column's values.

In the columns list, select Emergency Contact Phone to open its settings.
Expand Advanced options at the bottom of the column panel.
Check the Enable column security checkbox.
Select Save.

Now repeat the same process for the email column.

Select Emergency Contact Email from the columns list.
Expand Advanced options.
Check Enable column security.
Select Save.

What happens when column security is enabled?

Once you enable column security on a column, only users with the System Administrator security role can access it by default. Any user not defined in a column security profile will see the value displayed as ******** in forms and views.

This is the zero-trust baseline. In the next step, you will create column security profiles that grant specific users controlled access to these columns.

Don't see Enable column security?

The checkbox is located inside the Advanced options section of the column editor. You need to expand this section. It is collapsed by default. Also confirm you are editing the correct column (not viewing it in the table grid).

help me enable column security on my Dataverse column

Add sample deployment records with emergency contact data

You need actual data in the secured columns so you can verify masking behaviour later. Adding sample records now gives you something concrete to test against.

Navigate back to your deployment table's data view by selecting the table name, then selecting the data tab (or Edit in the command bar).
Add a new row (or edit an existing deployment record).
In the Emergency Contact Phone field, enter 555-123-4567.
In the Emergency Contact Email field, enter jsmith@agency.gov.
Add at least one more record with different contact data so you have multiple rows to inspect.
Confirm the data appears in the table view from your admin account.

Why can I still see the values?

As a System Administrator, you have full access to all secured columns by default. The ******** masking only applies to users without a column security profile granting them access. You will verify this from the test user's perspective in Step 5.

New columns not showing in the data view?

If your new columns do not appear in the table grid, you may need to add them to the current view. Select the + (column header) button in the grid to add a column, and choose your emergency contact columns from the list.

help me get my new columns to show up in the Dataverse table view

Your deployment table now has two secured PII columns with sample data ready for testing. Next up, you will create masking rules and column security profiles that control exactly who sees what.

Configure Masking Rules and Column Security Profiles

In the previous step, you enabled column security on both emergency contact fields. Right now, any non-admin user sees ******** for those columns. That is secure, but not useful for field supervisors who need partial visibility to confirm they have the right person on the line.

In this step, you will create a regex-based masking rule that reveals only the last 4 digits of phone numbers. You will also build two column security profiles that grant different levels of access to different user groups.

In this step, get ready to:

Create a secured masking rule that shows partial phone numbers.
Build a Field Supervisor Access profile with masked read-only permissions.
Build an Emergency Coordinator Access profile with full unmasked access.

Create a secured masking rule

A masking rule uses a regular expression to decide which characters to hide and which to reveal. You will create a rule that replaces all digits except the last four with # characters.

In Power Apps (make.powerapps.com), select your managed environment from the environment picker.
In the left navigation, select Solutions.
Open your solution (the one containing your deployment table).
Select Add existing or New to create a new component.
Select the Security menu option.
Choose Secured masking rule.
In the Name field, enter CLS_PhoneLastFour.
In the Display Name field, enter Phone Last Four Digits.
In the Regular Expression field, enter this regex pattern:

\d(?=\d{2}-\d{2}-\d{4}|\d-\d{2}-\d{4}|-\d{2}-\d{4}|\d-\d{4}|-\d{4})

In the Masked Character field, enter #.
In the test data field, enter 555-123-4567.
Verify the masked output preview shows ###-###-4567.
Select Save.

What does this regex do?

The pattern \d(?=...) matches any digit that is followed by a specific sequence of digits, dashes, and more digits. It effectively targets every digit except the last four in a phone number formatted as XXX-XXX-XXXX.

Each matched digit gets replaced by the masked character #. The last four digits do not match the pattern, so they remain visible.

Now apply the masking rule to the Emergency Contact Phone column.

Navigate to Tables in Power Apps and open your deployment table.
Under Schema, select Columns.
Open the Emergency Contact Phone column.
Expand Advanced options.
Select the Masking rule dropdown.
Choose Phone Last Four Digits.
Select Save.

Why not apply a masking rule to the email column too?

The email column uses full column hiding (********) instead of partial masking. This demonstrates the difference between the two approaches. Partial masking is useful when users need a hint of the value for verification. Full hiding is appropriate when no part of the value should be visible.

Don't see your masking rule in the dropdown?

Masking rules can only be added to secured columns in Managed Environments. Confirm your environment is managed in the Power Platform admin center. Also verify the column has Enable column security checked before the dropdown becomes available.

Help me troubleshoot why my masking rule isn't appearing in the Masking rule dropdown for my secured column.

Create the Field Supervisor Access profile

Column security profiles control which users can read, update, or unmask secured columns. You will create a profile that gives field supervisors read-only access with masked values.

Switch to the Power Platform admin center.
Select your environment.
Select Settings.
Select Users + permissions.
Select Column security profiles.
Select New Profile.
Enter Field Supervisor Access as the name.
Select Save.
Select the Users tab.
Select + Add Users.
Search for and select your test user (Field Tester).
Select Add.
Select the Column Permission tab.
Select the Emergency Contact Phone column, then select Edit.
Set Read to Allowed.
Set Read unmasked to Not Allowed.
Set Update to Not Allowed.
Set Create to Not Allowed.
Select Save.
Repeat for the Emergency Contact Email column with the same permissions (Read Allowed, all others Not Allowed).

What do these permissions mean?

Read Allowed lets the user see the column value, but because Read unmasked is Not Allowed, the masking rule stays active. The test user will see ###-###-4567 for the phone column instead of the full number.

For the email column (no masking rule applied), Read Allowed with no unmask permission shows the value in its masked default form: ********. The user knows the field exists but cannot see any part of it.

Create the Emergency Coordinator Access profile

Emergency coordinators need full access to contact details during a deployment. This profile grants unmasked read access plus create and update permissions.

Return to Column security profiles in the Power Platform admin center.
Select New Profile.
Enter Emergency Coordinator Access as the name.
Select Save.
Select the Users tab.
Select + Add Users.
Search for and select your admin account.
Select Add.
Select the Column Permission tab.
Select the Emergency Contact Phone column, then select Edit.
Set Read to Allowed.
Set Read unmasked to One Record.
Set Update to Allowed.
Set Create to Allowed.
Select Save.
Repeat for the Emergency Contact Email column with the same permissions (Read Allowed, Read unmasked One Record, Update Allowed, Create Allowed).

Why One Record instead of All Records for Read unmasked?

The One Record setting means the coordinator can unmask a single record at a time. This prevents bulk data exfiltration. Even trusted users cannot export an entire column of unmasked phone numbers in one query.

This is a key design principle for government workloads handling PII. Access is granted at the minimum scope needed to complete the task.

Not seeing your columns in the Column Permission tab?

Only columns with Enable column security checked appear in the Column Permission tab. Return to Power Apps, open each emergency contact column, and confirm that column security is enabled under Advanced options.

Help me figure out why my secured columns aren't showing in the Column Permission tab of my column security profile.

Your Dataverse security layer is now fully configured. Field supervisors see masked phone numbers and hidden emails. Emergency coordinators can unmask one record at a time. Next up, you will enable auditing so every access and change to these sensitive columns is logged in an immutable trail.

Enable Dataverse Auditing

Your deployment table now has column-level security protecting sensitive PII. But security controls are only half the picture. Without a record of who accessed or changed data, you cannot prove compliance or investigate incidents.

In this step, you will enable Dataverse auditing at three levels: environment, table, and column. This creates an immutable change log that captures every create, update, and delete operation on your deployment data.

In this step, get ready to:

Turn on environment-level auditing with a 365-day retention period.
Enable auditing on the deployment table and both emergency contact columns.
Verify that a test data change appears in the Audit Summary View.

Turn on environment-level auditing

Dataverse auditing works in layers. You must turn on auditing at the environment level first. Without this top-level switch, table and column auditing settings have no effect.

Switch back to the Power Platform admin center.
Navigate to your environment, then select Settings.
Select Audit and logs, then Audit settings.
Under Retain these logs for, select a retention period of 365 days.
Select Global Audit Settings.
Turn on Start Auditing, then select OK.
Select Save.

Why 365 days?

The default retention period is only 30 days. Government compliance frameworks typically require at least one year of audit records. A 365-day retention period satisfies most federal accountability requirements while keeping storage costs manageable.

Dataverse supports retention periods from 1 to 365,000 days, so you can adjust this later if your organization needs longer retention.

What does Dataverse auditing capture?

Auditing logs create, update, delete operations, sharing changes, N:N associations, security role changes, and deletion of audit logs.

It does NOT capture table/column definition changes, authentication, retrieve operations, or export operations. For those, you would use other Microsoft 365 audit capabilities.

Enable table-level and column-level auditing

With environment auditing active, you now need to tell Dataverse which specific tables and columns to track. Turning on auditing at the environment level is the master switch. You still need to opt in each table and each column individually.

Switch back to Power Apps (make.powerapps.com).
Select your environment and navigate to Tables.
Open your deployment table.
Select Properties.
Expand Advanced options.
Check Audit changes to its data.
Select Save.

Now enable auditing on each of the secured columns individually.

Under Schema, select Columns.
Open the Emergency Contact Phone column.
Expand Advanced options.
Check Enable auditing.
Select Save.
Repeat for the Emergency Contact Email column: open it, expand Advanced options, check Enable auditing, and Save.

Why enable auditing at all three levels?

Dataverse uses a layered approach: environment, table, and column. The environment switch is the master control. Table-level auditing tells Dataverse to track changes on that specific table. Column-level auditing narrows it further to individual fields.

All three must be on for changes to your emergency contact columns to appear in the audit log.

Don't see the Enable auditing checkbox?

Make sure you are expanding Advanced options within the column editor, not the table properties. The auditing checkbox for columns is separate from the table-level checkbox.

Also confirm you have the System Administrator or System Customizer role. Only these roles can turn auditing on or off.

help me find the Enable auditing checkbox for my Dataverse column

Make a test change and verify it in the audit log

With auditing configured at all three levels, you can now generate a test event and confirm it appears in the audit log. This proves your configuration is working before you hand the environment to your test user in the next step.

In Power Apps, open your deployment table's data.
Select one of your existing deployment records.
Update the Emergency Contact Phone field to a different value (for example, change 555-123-4567 to 555-987-6543).
Save the record.

Now check the audit log for the change you just made.

Switch back to the Power Platform admin center.
Navigate to your environment, then select Settings.
Select Audit and logs, then Audit Summary View.
Look for an update event on your deployment table showing the Emergency Contact Phone change.
Confirm the audit entry shows the old and new values in masked form.

Why are the values masked in the audit log?

Dataverse protects PII even within the audit trail. The audit log shows masked values in the before-and-after update events. This means even users with access to the audit log cannot extract raw PII without the appropriate unmasked read permissions.

Don't see your audit entry yet?

Audit log entries may take a few minutes to appear. Wait 2-3 minutes and refresh the Audit Summary View.

If the entry still does not appear, confirm that Start Auditing is turned on at the environment level. Table and column auditing have no effect without the environment-level switch being active.

help me troubleshoot missing audit log entries in Dataverse

Your deployment table now has a complete audit trail. Every change to your emergency contact data is logged with who made it, when, and what changed. Next up, you will verify that your security controls work end-to-end by testing with the non-administrator account.

Verify Security Controls with the Test User

Your security architecture is configured and auditing is live. The remaining question is whether the controls actually hold up under real conditions.

In this step, you will log in as the non-administrator test user to prove that masking and access restrictions work. You will also confirm that admin-level unmasking functions correctly and that the audit trail captures every relevant event.

In this step, get ready to:

Verify the test user sees masked and hidden column values.
Confirm the admin account can unmask protected values.
Review audit log entries for all data access events.

Log in as the test user and confirm masking works

The true test of column-level security is what a restricted user actually sees. You will open a separate browser session to simulate the test user's experience without logging out of your admin account.

Open an InPrivate (Edge) or Incognito (Chrome) browser window.
Navigate to make.powerapps.com and sign in with your test user credentials (the Field Tester account you created in Step 1).
Select your environment from the environment picker in the top-right corner.
In the left navigation, select Tables.
Open your deployment table and select the Data tab to view records.

You should see your sample deployment records. Look at the Emergency Contact Phone and Emergency Contact Email columns.

Confirm the Emergency Contact Phone column shows masked values like ###-###-4567 (last four digits visible, rest replaced with # characters).
Confirm the Emergency Contact Email column shows ******** (completely hidden because no masking rule is applied to this column).
Click on a deployment record to open it, then try to edit one of the secured columns.
Verify the update is blocked. The field should be read-only for this user.

Why does the phone show partial values while email is fully hidden?

The Emergency Contact Phone column has the CLS_PhoneLastFour masking rule applied, so users with Read access (but not Read unmasked) see a partially masked version. The email column has no masking rule, so Dataverse falls back to its default behavior of showing ******** for any secured column without a profile granting full access.

Test user sees full values or gets an access error?

If the test user sees unmasked values, check that they are assigned to the Field Supervisor Access profile (not Emergency Coordinator Access). Only Field Supervisor Access restricts Read unmasked to Not Allowed.

If the test user gets an error loading the table, confirm they have the Basic User security role assigned in the environment. Without it, they cannot access any table data.

Why can my test user see full phone numbers or get a permissions error?

Verify admin unmasked access

Your admin account is assigned to the Emergency Coordinator Access profile, which grants Read unmasked at the One Record level. This means you can reveal the full value one record at a time.

Switch back to your original browser window where you are signed in as the System Administrator.
In Power Apps, open your deployment table and select a record that has emergency contact data.
Look for the Read unmasked icon next to the Emergency Contact Phone field.
Click the icon to reveal the full phone number for that record.
Confirm the unmasked value matches what you originally entered (e.g., 555-123-4567).

Why is the Read unmasked icon only visible to administrators?

Per current platform behavior, the Read unmasked icon is only visible to users with the System Administrator security role who also have Read Unmasked permissions. Microsoft is working on enabling visibility for non-administrator users in a future update.

This means the test user (Field Tester) would not see the unmask icon even if their profile granted Read Unmasked One Record. The restriction is enforced at the data level regardless of icon visibility.

All unmasked reads are audited

Every time someone uses the Read unmasked action, Dataverse creates an audit entry. This creates accountability for anyone who accesses the full PII value. You will confirm this in the next substep.

Don't see the Read unmasked icon?

Make sure you are viewing the record in the form view (not the grid/table view). The icon appears next to the individual field on the record form.

Confirm your admin account is listed in the Emergency Coordinator Access column security profile with Read unmasked set to One Record.

Help me find the Read unmasked icon in my Power Apps deployment record

Review the audit log for access events

The final verification confirms that your auditing trail captured every interaction. You will look for three types of entries: the data update from Step 4, your unmasked read, and any test user access attempts.

Return to the Power Platform admin center in your admin browser.
Navigate to your environment, then select Settings.
Expand Audit and logs and select Audit Summary View.
Use the column filters to narrow results to your deployment table.

Look for the following entries in the audit log:

The update event from Step 4 where you changed the Emergency Contact Phone value. This should show old and new values as masked (e.g., ###-###-4567).
A read-unmasked access event from when you clicked the unmask icon in the previous substep.
Any access events from the test user's session (if user access logging is enabled).

Why do audit entries show masked before-and-after values?

Even within the audit logs, PII is protected. The official documentation confirms that audit logs show masked values in the before-and-after update events. This means that even an admin reviewing audit history cannot accidentally see full PII values through the log interface.

This is a deliberate design choice: the audit trail proves that changes happened and who made them, without creating a secondary copy of the sensitive data in plaintext.

Audit entries may take a few minutes to appear

If you do not see the latest entries immediately, wait 2-5 minutes and refresh the Audit Summary View. Dataverse processes audit writes asynchronously.

Missing audit entries?

Confirm auditing is still enabled at the environment level (Settings > Audit and logs > Audit settings > Start Auditing should be on).

Check that both the deployment table and the emergency contact columns still have auditing enabled. If you accidentally toggled them off, new events will not be logged.

Help me find my missing audit entries in the Power Platform admin center

Secret mission

Build a NIST SP 800-53 AU Compliance Evidence Matrix

Your auditing configuration is solid, but can you prove it meets government compliance standards? In this mission, you'll map your Dataverse auditing setup to specific NIST SP 800-53 Rev. 5 Audit and Accountability (AU) controls. This is the exact type of documentation required for real FedRAMP authorization packages.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The test user account has a Power Apps Premium trial license that is free for 30 days but costs $20/user/month after the trial ends.

Cost warning

The Field Tester account's Power Apps Premium trial license converts to a paid subscription ($20/user/month) after 30 days if not cancelled. If you do not plan to continue with Project 3 within that window, delete the test user to avoid charges.

Resources you used:

One Microsoft 365 user account (Field Tester) with a Power Apps Premium trial license.
Two column security profiles (Field Supervisor Access and Emergency Coordinator Access) in your Dataverse environment.
One secured masking rule (CLS_PhoneLastFour) in your solution.
Audit log data stored in Dataverse log storage (included in existing Dataverse capacity).

Keep everything running

No action needed. Choose this if you are still actively building and plan to continue with Project 3. The trial license is free for 30 days.

Leave the test user and security configurations in place.
Auditing continues logging events against your existing Dataverse storage capacity.
Set a calendar reminder for 30 days from now to either continue or clean up before the trial converts to paid.

Pause - I'll come back to this later

Disable the test user account to prevent sign-in while keeping all security configurations intact. You can re-enable the account when you are ready to continue.

In the Microsoft 365 admin center, navigate to Users, then Active users.
Select the Field Tester account.
Select Block sign-in, check Block this user from signing in, then select Save changes.
Column security profiles and auditing remain configured and will resume working when you re-enable the user.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each item below to fully clean up.

Delete the test user:

In the Microsoft 365 admin center, navigate to Users, then Active users.
Select the Field Tester account to open their details.
Select Delete user, confirm your choices on the deletion page, then select Delete user again.

Delete the column security profiles:

In the Power Platform admin center, navigate to your environment, then select Settings.
Select Users + permissions, then Column security profiles.
Select the Field Supervisor Access profile and delete it.
Select the Emergency Coordinator Access profile and delete it.

Remove the masking rule:

In Power Apps (make.powerapps.com), open your solution.
Navigate to Security, then Secured masking rules.
Select the CLS_PhoneLastFour rule and delete it.
Open the Emergency Contact Phone column, expand Advanced options, and uncheck Enable column security. Save the column.
Repeat for the Emergency Contact Email column.

Disable auditing:

In the Power Platform admin center, navigate to your environment, then select Settings.
Select Audit and logs, then Audit settings.
Select Global Audit Settings, turn off Start Auditing, then select OK.
Select Save.

What about existing audit log data?

Disabling auditing stops new events from being logged but does not delete existing audit records. Those records remain until the retention period (365 days) expires naturally.

This is by design to prevent accidental destruction of compliance evidence.

Nice Work!

You just hardened a Dataverse deployment table with enterprise-grade security controls. Sensitive PII is masked for unauthorized users, every data change is captured in an immutable audit trail, and you can demonstrate compliance alignment to government security frameworks.

You've learned how to:

Configured column-level security with a custom regex masking rule that shows only the last 4 digits of phone numbers to unauthorized users while fully hiding email addresses.
Created two column security profiles with distinct access levels: Field Supervisor (masked read-only) and Emergency Coordinator (full unmasked access).
Enabled Dataverse auditing at environment, table, and column levels with a 365-day retention period and verified the full security posture with a non-administrator test account.
Secret Mission: Built a NIST SP 800-53 AU compliance evidence matrix mapping your Dataverse auditing configuration to specific control requirements.

Ready to quiz yourself?