Chapter 15: Security and Compliance

Objectives

By the end of this chapter you will be able to:

• Explain what DataClassification communicates and why it isn’t optional
• Audit an existing table’s fields for correct classification
• Scope a permission set to the minimum access a role actually needs
• Distinguish object-level permission from field-level sensitivity
• Apply security best practices you can defend in a code review

15.1 DataClassification is a compliance signal, not decoration

Every field you’ve written since Chapter 7 has had a DataClassification. For privacy and compliance purposes, that property tells Business Central (and anyone auditing your extension) what kind of data the field holds:

• CustomerContent for business data that belongs to the customer
• EndUserIdentifiableInformation for anything that identifies a specific person
• SystemMetadata for technical housekeeping fields

Setting every field to ToBeClassified and moving on defeats the purpose. It’s the field-level equivalent of leaving a form blank.

15.2 Auditing Loan Repayment Schedule

Here are the fields from Chapter 7, reviewed with compliance in mind:

None of these fields identify a specific person, so CustomerContent across the board is defensible here. Suppose you later added a "Borrower Name" field directly to this table instead of looking the name up from a Customer or Loan record. That field would need EndUserIdentifiableInformation, which is one more reason, besides normalization, to keep personal data in its own table.

Hint: When in doubt, ask: “If this field’s value leaked, would it identify a real person?” If yes, it’s EndUserIdentifiableInformation, not CustomerContent.

15.3 Scoping a permission set to a role, not “everyone”

Chapter 11 granted full access (RIMD on the table data and X on every object) in one permission set. In practice, different roles need different access:

permissionset 50103 "Loan Repayment - View"
{
    Assignable = true;
    Caption = 'Loan Repayment (View Only)';

    Permissions =
        table "Loan Repayment Schedule" = X,
        tabledata "Loan Repayment Schedule" = R,
        page "Loan Repayment Schedule List" = X;
}

permissionset 50104 "Loan Repayment - Full"
{
    Assignable = true;
    Caption = 'Loan Repayment (Full Access)';
    IncludedPermissionSets = "Loan Repayment - View";

    Permissions =
        tabledata "Loan Repayment Schedule" = IMD,
        codeunit "Loan Repayment Mgt." = X;
}

Hint: IncludedPermissionSets lets the “Full” set build on top of “View” instead of repeating its permissions. It also means that a later change to what “View” grants applies automatically everywhere “View” is included, so you have one set to update instead of several.

15.4 Field-level considerations

Object-level permissions (table, page, codeunit) control whether a user can open something at all. On their own, they don’t hide specific sensitive fields from a user who has table access. For that you need page design decisions on top of correct DataClassification: leave the field off a page entirely, or make it visible only to certain roles through a page extension.

15.5 Best practices for security and compliance

• Classify each field honestly. Don’t blanket-set a classification on the table, and never leave a field at ToBeClassified in anything you ship.
• Design permission sets around roles, not around “give this person what they’re asking for right now.”
• Build layered permission sets with IncludedPermissionSets instead of repeating the same grants across several sets.
• Treat page design as part of security, along with permissions. How a page is built can keep a user who has table access away from a sensitive field.

Chapter summary

In this chapter you:

• Learned to treat DataClassification as a compliance signal, not boilerplate
• Audited the classifications on the Loan Repayment Schedule table
• Split one broad permission set into role-scoped ones
• Learned the difference between object-level and field-level security

Tasks

1. Audit your table. Go through every field on Loan Repayment Schedule and confirm its DataClassification matches the table in 15.2. Fix any that don’t.
2. Split the permission set. Replace the single permission set from Chapter 11 with the “View” and “Full” pair from 15.3.
3. Assign roles. Decide which of your test users would get “View” and which would get “Full,” and write one sentence justifying each.
4. Try it yourself. Suppose a future chapter adds a "Borrower Name" field directly onto Loan Repayment Schedule (skipping the lookup to a Loan table). What DataClassification would it need, and what page-design decision would you make to limit who sees it?

Check your work: compare your permission sets against the reference solution in the Chapter 15 solutions.