All Things Dynamics

Building a Business Process Focused Security Strategy in Dynamics 365 Finance & Supply Chain

When teams think about security in Dynamics 365 Finance & Supply Chain, the conversation often starts with roles:

  • “What roles do we need?”
  • “Which standard roles can we use?”
  • “Who needs access to which menus?”

While those questions aren’t wrong, they’re incomplete.
A strong security design doesn’t start with roles, it starts with how the business actually works.

A security strategy is the blueprint that connects business processes, user responsibilities, risk controls, and system capabilities into something that is secure, maintainable and usable long after go live.

This article explains what goes into a good security strategy, why each piece matters, and how a process focused approach leads to better outcomes for both implementers and clients.


What Is a Security Strategy (Really)?

A security strategy answers a few fundamental questions:

  • Who performs each step of the business?
  • What actions must they perform to do their job?
  • Where do controls need to exist to reduce risk?
  • How will access be managed over time?

In Dynamics 365 Finance & Supply Chain, security is not just about protecting data. It is about enabling people to execute business processes correctly, while ensuring compliance, auditability, and scalability.

A good security strategy:

  • Supports business processes end-to-end
  • Applies least privilege by design
  • Enforce segregation of duties
  • Reduce long term operational effort
  • Avoids role sprawl and “security debt”

Start With Business Processes, Not Roles

Security design works best when it follows business processes such as:

  • Procure to Pay
  • Order to Cash
  • Record to Report
  • Plan to Produce

Each process has:

  • Distinct steps
  • Different personas involved
  • Natural control points

Instead of asking "What role does an AP Clerk get?, ask:

"What steps does an AP Clerk perform in Procure to Pay?

That shift changes things quite a bit.

Why this matters

  • Access becomes intentional, not inherited
  • Controls align naturally with responsibilities
  • Security discussions are easier for business stakeholders to engage in

Map Personas to Process Responsibilities

Once processes are defined, identify personas, not job titles, but sets of responsibilities.

For example:

Process Persona Responsibilities
Procure to Pay AP Clerk Enter invoices, perform matching
Procure to Pay AP Manager Review and approve invoices
Record to Report GL Accountant Prepare journals
Record to Report Finance Manager Approve and post journals

This mapping becomes the foundation of security design.

Why this matters

  • Prevents “one size fits all” roles
  • Makes segregation of duties visible early
  • Clarifies what access is truly required

Design Security at the Duty Level

Dynamics 365 security is hierarchical:

  • Roles
  • Duties
  • Privleges
  • Permissions

From a strategy standpoint, duties are the most important level.

Duties represent pieces of a business process; for example:

  • Maintain Vendors
  • Approve purchase orders
  • Post journals

A strong security strategy states clearly:

  • Customization happens at the duty level
  • Roles are assembled from reusable duties
  • Roles are not copied and modified endlessly

Why this matters

  • Reduces the number of custom roles
  • Makes security easier to maintain
  • Improves upgrade safety
  • Simplifies auditing and troubleshooting

Use Workflow as a security control

Workflow is often viewed as automation, but it is also one of the most powerful security tools in Finance & Supply Chain.

Approval Workflows:

  • Allow users to initiate transactions without excessive permissions
  • Enforce policy consistently
  • Provide traceability and audit evidence

For example:

  • A user can create a journal but cannot post it
  • Posting requires approval based on amount or risk

Why this matters

  • Reduces the need for elevated access
  • Supports compliance without slowing the business
  • Keeps security aligned with real world controls

Build Segregation of Duties into the design

Segregation of duties (SoD) should not be discovered during UAT or audits. It should be designed intentionally.

A good security strategy identifies:

  • High risk process combinations
  • Where conflicts could occur
  • How those conflicts are prevented

Example controls:

  • Separate duties for vendor creation and payment
  • Workflow approval for posting journals
  • Independent approval for inventory adjustments

Why this matters

  • Reduces fraud risk
  • Prevents last minute role changes
  • Avoids audit findings after go live

Address Legal Entity and Data Access Early

Legal entity access is not just a technical decision, it reflects how the business operates.

Key questions:

  • Which personas work in a single legal entity?
  • Which operate across multiple legal entities?
  • Are there shared service or intercompany scenarios?

A security strategy should describe how data access supports business structure, not just state that “users are restricted by company”.

Why this matters

  • Prevents rework late in the project
  • Avoids over provisioning
  • Supports shared services cleanly

Plan for Ongoing Security Governance

Security does not end at go live.

A complete security strategy includes:

  • How users are onboarded and offboarded
  • How access is reviewed periodically
  • Who owns the security decisions post go live.

This is often overlooked but critical for sustainability.

Why this matters

  • Prevents access creep
  • Keeps roles aligned with responsibilities
  • Reduces support burden over time.

Call Out What You Intentionally Avoid

An effective security strategy is also clear about anti‑patterns it avoids, such as:

  • One large role per department
  • Menu level permission hacking
  • Copying roles without understanding duties
  • Designing security after testing starts

Being explicit here sets expectations and prevents bad habits from creeping in.


Bringing it all together

A business‑process‑focused security strategy is not about making security more complex, it’s about making it more intentional.

When security is designed around how people actually work:

  • Users get access that makes sense
  • Risks are controlled by design
  • Audits are smoother
  • The system is easier to support and extend

Most importantly, security stops being a barrier and becomes an enabler of the business.