Security, Governance & Trust
Protect access, data, change
and accountability.
ComplexityControl
Business-critical platforms hold financial, operational, customer and service information that organisations rely on every day. Security is therefore not only a technical configuration. It is also about what must be protected, who or what may act, what they may access, what they may change, who approves it, how the control is proven and who owns the residual risk.
Identity. Access. Data. Action. Change. Audit. Review.
Security is not one control. It is a chain of decisions.
Who gets access? To what? For how long? What can they do? Who approves it? What is recorded? What happens when their role changes? The strength of the model depends on those decisions remaining connected.
In short
Twelve things a senior reader should take from this page.
The specialist detail sits further down and on the platform pages. This is the executive layer.
- 01Security is a shared responsibility, and every material boundary needs an owner.
- 02Start with business consequence and data sensitivity, not with a control list.
- 03Identity and access should follow business responsibility.
- 04Privilege is limited, approved and reviewed rather than standing by default.
- 05Environments are separated and production change is controlled.
- 06Data and integrations keep explicit ownership.
- 07Non-human identities still need a human owner.
- 08AI and automation act inside approved boundaries.
- 09Security is tested before production, including what should not be possible.
- 10Exceptions and residual risks stay visible, owned and time-bound.
- 11Controls continue after go-live.
- 12InteliSense provides business applications security and governance, not a replacement cyber-security function.
Security is built into how we design and operate business applications. It is not presented as a replacement for the customer's wider cyber-security capability.
InteliSense specialises in business applications security and governance within the Microsoft solutions it designs, implements, integrates and supports.
Where scoped, this may include
Business applications security and governance.
- Role and access design
- Least privilege
- Segregation-of-duties design
- Environment governance
- Application and data access architecture
- Integration identity and access
- Deployment and change governance
- Support access
- AI and agent controls
- Application security testing
- Production readiness
- Governance review
Not automatically provided
Capabilities we do not claim.
We would only mention any of these if a formally approved capability existed.
- Security operations centre
- Managed detection and response
- Endpoint security
- Network security
- Threat hunting
- Forensic incident response
- Penetration testing
- Red teaming
Risk and consequence
The higher the consequence and the harder an action is to reverse, the stronger the control should become.
A control list on its own does not say when a stronger control is required. Consequence does.
- Data sensitivity, using the customer's classification model where one exists
- Action authority: read, recommend, prepare, approve or execute
- Business consequence if the action or access is wrong
- Actor: internal user, external user, partner, service identity, or AI and automated process
- System criticality to operation
- Reversibility of an incorrect action
The control chain
Trust comes from boundaries that are understood.
Each step answers one question. When any step is undefined, the answer usually becomes broader access than anyone intended.
Identity
Who or what are you?
Authentication
Can we verify you?
Authorisation
What are you allowed to do?
Data access
What information can you see?
Action
What can you change or execute?
Change
What may be altered in production?
Audit
What happened, and can it be evidenced?
Review
Should the access still exist?
Identity
Access starts with a trusted identity, and not every identity is a person.
Identity architecture belongs to the customer. We design and operate business applications aligned to the customer's approved Microsoft security model. These identity types are not all governed by an identical mechanism.
Human identity
An employee or named user inside the organisation.
External or guest identity
An external person, contractor or partner organisation.
Privileged identity
Administrative or elevated access, with higher accountability.
Non-human identity
A service, application or integration identity.
AI or agent identity
The identity context under which an AI capability obtains data or performs an action.
- Microsoft Entra ID
- Named users
- Service principals where appropriate
- Managed identities where appropriate
- Multi-factor authentication
- Conditional Access where the customer architecture supports it
Least privilege
People should have the access they need. Not the access that is easiest to grant.
Access can be shaped by several dimensions at once, which is what makes role design a design activity rather than an administrative one.
- Role
- Team
- Business unit
- Legal entity
- Environment
- Application
- Record
- Function
Broad access is not a substitute for good role design.
Security roles
Role design should reflect responsibility, not convenience.
The design principles remain consistent across Finance & Supply Chain, Business Central, Dataverse, Power Platform and Fabric. The platform mechanisms differ.
Business responsibility
Access should follow what the person is accountable for.
Segregation
Some combinations of duty should not sit with one person.
Operational need
People still need to complete their work without workarounds.
Supportability
A role model nobody can explain becomes impossible to maintain.
Governance
Someone must own approval, change and review of the model.
Segregation of duties considers what a user can do in combination rather than permission by permission. Create vendor, change bank details and approve payment is the classic illustration, and it is not the only relevant conflict. Automated segregation checking only exists where it has been specifically implemented and agreed.
Joiners, movers, leavers
Access needs a lifecycle, including access that is not held by a person.
Access that was appropriate six months ago may not be appropriate today. Review timing belongs to the customer's policy and the agreed service rather than a universal rule published here.
Joiner
Identity and access are created for a defined job, and approved.
Provision
Access is granted to the approved role, not copied from a colleague.
Mover
Responsibilities change, so old access is removed as new access is granted.
Leaver
Access is removed and records and responsibilities are reassigned.
External end
Partner, contractor or guest access expires or is removed.
Service retirement
An application or service identity is removed once its dependencies are safely retired.
Review
Access is re-checked against what the person or service actually does.
Privileged access
Higher privilege should create higher accountability.
Standing privilege should be justified rather than treated as the default.
Named ownership
Privileged access belongs to a person, not a shared login.
Minimum duration
Elevation should last as long as the task, not the project.
Approval
Someone accountable agrees the elevation before it happens.
Audit
Privileged actions should be visible afterwards.
Review
Standing privilege should be justified rather than treated as the default.
- Time-limited elevation
- Just-in-time privilege
- Privileged identity management
- Separate administrative identities
- Emergency or break-glass access with an owner
- Recurring access review
- InteliSense does not automatically deploy or manage these controls
A non-human identity still needs a human owner.
Service principals, managed identities, application registrations, integration identities, Power Automate connections, scheduled jobs, gateways, AI agents and other service accounts all belong in the same lifecycle.
Purpose
Why the identity exists at all, in business terms.
Owner
A named human owner. A non-human identity still needs one.
Identity
Which identity type is appropriate for the job.
Permissions
Scoped deliberately rather than inherited broadly.
Credential method
Secret, certificate, key or managed identity, with a renewal path.
Dependencies
What stops working if it changes or is removed.
Monitor
Failure is visible to somebody who can act on it.
Review
Still required, still correctly scoped, still owned.
Rotate or renew
Where the credential method requires it.
Retire
Removed once the dependency is safely retired.
- Service principals
- Managed identities
- Application registrations
- Integration identities
- Power Automate connections
- Scheduled jobs
- Gateways
- AI agents
- Other service accounts
Secrets and credentials
A credential without a known owner or renewal path is an operational dependency waiting to fail.
Where a secret or certificate exists, the owner and the renewal path should be known before the expiry date is discovered by an outage.
- Identity it belongs to
- Authentication mechanism
- Secret, certificate or API key
- Owner
- Storage
- Expiry
- Rotation
- Revocation
- Dependency
- Audit
External and partner access
External access should have an owner and an end condition, not simply an invitation.
Guests, contractors, partner organisations and external experiences all widen the boundary of the platform.
- Identity type
- Organisation
- Business purpose
- Sponsor or owner
- Data boundary
- Role and access
- Expiry or end condition
- Periodic review
- Offboarding
Environment governance
Production should not become the development environment.
The more important the process, the stronger the environment and deployment control should become. Separation is only useful if the rules for each environment are explicit.
- Purpose
- Who can access it
- Who can deploy into it
- Who holds administrative rights
- What production information it may contain
- How and when it is refreshed
- Which connections it holds
- Whether it is externally exposed
- Who owns it
Change governance
A technically possible change is not automatically an approved change.
The same route applies whether the change is configuration, code, integration, security, data, workflow or reporting.
Request
The change is captured with a business reason.
Assess
Understand impact on process, data, integration and security.
Approve
Someone accountable decides that it should proceed.
Build
The change is developed under normal delivery discipline.
Test
Behaviour is proven, including what should not be possible.
Review
The change is checked before it reaches production.
Deploy
Release is controlled rather than opportunistic.
Validate
The business confirms the intended outcome.
Audit
There is a record of what changed and who agreed to it.
- Who approved it?
- Where was it tested?
- What is the dependency?
- What happens if it fails?
- Who validates after deployment?
- Configuration, code, integration, security, data, workflow and reporting changes all reach the same environment
Development governance
Customisation should increase capability without creating unmanaged risk.
These are the engineering practices we can evidence. What was built, why, who reviewed it and who can support it next year matters more than the tooling.
- Source control
- Peer review
- Testing
- Environment separation
- Deployment control
- Documentation
- Ownership
- Supportability
Technology can store the data. The business still needs to own it.
Ownership means responsibility for definition, quality, access, use, retention and disposal.
- Data ownership: who is accountable?
- Data access: who can see and use it?
- Data location: where is it processed and stored?
- Data retention: how long should it remain?
- Data disposal: how is it removed according to approved policy?
- Data sharing: which other systems or organisations receive it?
Data minimisation
Store what the process genuinely needs.
This is an architecture and design principle rather than a universal technical deletion rule. The exact requirement depends on customer policy, business need, retention and applicable regulatory requirements.
Transformation risk
Data migration temporarily creates additional access and handling risk.
Migration is often the point at which the most sensitive data is handled by the most people.
Extract
Data is taken from the source under agreed authority.
Stage
It sits somewhere temporarily, which creates additional handling risk.
Clean
Quality issues are addressed before they are inherited.
Transform
Data is mapped to the new model.
Test
Loads are proven before they matter.
Load
Data enters the target environment in a controlled sequence.
Validate
The business confirms the result is usable.
Dispose or retain
Disposed of or retained according to the agreed migration, security and records policy once temporary processing is complete.
- Extracts
- Staging data
- Test copies
- Reconciliation files
- Logs
- Temporary access
- Each needs a location, an owner, a retention position and a disposal route
Integration security
An integration should not become a route around the security controls of either system.
Data moving between systems still needs identity, permission, ownership and a support route.
- Business purpose
- Source and target
- Identity
- Authentication
- Permission
- Data scope
- Secret or certificate
- Endpoint
- Encryption where applicable
- Error handling
- Logging
- Monitoring
- Support owner
- Third-party responsibility
Security confidence gates
Security confidence should increase through evidence, not because a checklist was completed.
Four points where the control model has to be re-confirmed. Each can legitimately conclude that scope should be redesigned, remediation is required, or an exception must be recorded.
Gate 1
Security context
What actually needs protecting here?
Confirmed before architecture is committed. Control design without context produces either excess friction or excess access.
Confirmed at this gate
- Business process and criticality
- Data sensitivity
- Actors and users, including external parties
- Environments
- Customer control and regulatory requirements
- Integrations, AI and automation, and the named security or risk owner
Decision
Proceed · Obtain more information · Redesign scope
Gate 2
Control design
Is the control model coherent, not just present?
Confirmed once the design exists and before it is built. An exception at this point is a decision, not a failure.
Confirmed at this gate
- Identity, authentication, access and roles
- Segregation and privilege
- Environments and data
- External access, integration identities and secrets
- Logging and continuity
- AI and action boundaries, and supplier responsibilities
Decision
Approved design · Remediate · Exception required
Gate 3
Security proof
Has the control been proven, or only configured?
Confirmed before production, proportionate to risk. Testing should prove who cannot do something, not only who can.
Confirmed at this gate
- Positive and negative access testing
- Privileged and cross-boundary access
- Production and deployment rights
- Integration identity and data exposure
- Audit, logging and support access
- AI and action controls, and relevant continuity evidence
Decision
Production candidate · Remediate · Re-test
Gate 4
Operate and review
Is the model still true six months later?
Confirmed in operation. Security confidence should increase through evidence, not because a checklist was completed.
Confirmed at this gate
- Joiner, mover and leaver processes
- Recurring access and privileged-access review where agreed
- Non-human identities owned and credentials managed
- Monitoring route and security escalation
- Supplier access and change control
- Exceptions, evidence and review triggers
Decision
Operate · Remediate · Optimise · Recover
Security by design
Security belongs in every stage, not only before go-live.
Security starts during qualification, design, data, integration, testing and cutover, aligned to the implementation method.
Discover
Data sensitivity, users, roles, partners, regulation and critical processes.
Design
Roles, data boundaries, integration, environments, external access, audit and approval.
Build
Development governance, review and environment separation.
Test
Role testing, negative testing, access boundaries and data exposure.
Deploy
Access review, admin accounts, deployment rights and integration credentials.
Operate
Support access, monitoring, logging and change control.
Review
Access and controls re-examined as the organisation changes.
Go-live
Access granted during a project is not automatically the access the live service should keep.
- Final access review
- Admin accounts
- Deployment rights
- Production access
- Support access
- Leaver checks
- Integration credentials
- Environment configuration
Security testing
Testing should prove who cannot do something, not only who can.
Depth should follow consequence. A reporting change and a payment approval boundary do not warrant the same evidence.
- Expected access
- Denied access
- Legal entity or business boundary
- Record and data boundary
- Privileged access
- External access
- Deployment rights
- Service identity
- Integration identity
- Workflow approval
- AI action boundary
An exception should be visible, owned and temporary where possible. Hidden exceptions are unmanaged risk.
Not every exception is acceptable. Some should be refused, and some should stop the change reaching production.
Control expectation
What the design says should be true.
Exception
What is actually the case, stated plainly.
Business reason
Why the deviation exists at all.
Risk
What could go wrong as a result.
Compensating control
What reduces that exposure in the meantime.
Owner
A named person, not a team inbox.
Approval
Accepted by somebody with authority to accept it.
Review or expiry
A date, not an indefinite state.
Where exceptions genuinely occur
Real programmes sometimes need a controlled deviation.
- Legacy service identities
- Temporary production access
- Incomplete segregation
- External system limitations
- Temporary use of sensitive test data
- Unsupported authentication constraints
Control and evidence register
A security control is stronger when the organisation can show who owns it, how it was tested and what evidence supports it.
Held as a working register rather than displayed as a compliance checklist.
- Control or requirement
- Risk or reason
- Owner
- Implementation
- Evidence
- Test
- Exception
- Residual risk
- Approval
- Review trigger
Audit and logging
A log nobody reviews is storage. A log with an owner is control.
What is recorded depends on the platform capability configured for your environment. We do not claim that every action everywhere is immutable, and we do not promise audit coverage the configuration does not provide.
Log
Something was recorded.
Audit evidence
The record is sufficient for the required business or control purpose.
Owner
Someone is responsible for reviewing it.
Action
An issue identified from the evidence has a route.
- User action
- Record change
- Approval
- Deployment
- Integration event
- AI recommendation
- Security change
- Support action
Monitoring
Monitoring is only delivered where it forms part of the agreed service.
Each monitored area needs an owner and a response, otherwise it is observation rather than control.
- What is monitored
- Threshold or condition where applicable
- Owner
- Response
- Escalation
- Service hours
- Third-party dependency
Security incident routing
Naming the type of issue early usually gets it to the right owner faster.
InteliSense is not a cyber incident-response provider, and we do not own forensic investigation.
Application or support issue
Expected business application behaviour is not working. It follows the agreed support route.
Application security concern
A possible access, control or configuration issue inside the supported application scope.
Suspected cyber incident
Follow the customer's approved cyber or security incident route. InteliSense is not a cyber incident-response provider.
Suspected InteliSense vulnerability
Ask us to agree a secure channel. Do not include vulnerability detail in a general enquiry form.
Recovery
Wider platform or governance control has materially deteriorated.
Do not enter passwords, credentials, access tokens, personal information or vulnerability details in this form. Tell us the topic only and we will agree an appropriate route. A published secure vulnerability-reporting route is not yet available, so please request a secure channel without including any detail of the issue itself.
Support access
Support should not require permanent unrestricted access.
Access held to operate a service should be as visible and as removable as any other access.
- Named support access
- Minimum privilege
- Environment-specific access
- Customer approval where appropriate
- Temporary elevation
- Audit
- Removal
Continuity
Availability is a business question as well as a platform question.
Continuity is broader than one Microsoft service, so it should be designed across four layers rather than assumed from one application.
Platform availability
The underlying Microsoft service.
Application recovery
Configuration, data and application state.
Integration continuity
The cross-system process, not only one application.
Business continuity
How the organisation operates while capability is unavailable.
- Recovery owner
- Restore owner
- Critical data
- Integration dependency
- Manual fallback
- Validation
- Return-to-service decision
- We do not publish generic recovery time or recovery point figures
AI with boundaries
An agent should have boundaries before it has autonomy.
An AI capability is a participant in the process, so it should be governed like one. The executive control model sits here. The deeper model, evaluation and predictive detail sits on the specialist pages.
Purpose
What the capability is for, in business terms.
Data
Which approved sources it may use, and why.
Identity
The identity context under which it operates.
Permission
Explicitly approved for that purpose and process.
Action
What it may do, not only what it may say.
Oversight
Human involvement proportionate to consequence.
Evaluation
Output quality has a measure, not an impression.
Audit
What was requested, approved and done.
Failure
A defined outcome when something goes wrong.
Review
Approval, change and retirement have an owner.
AI data access
AI should never gain broader access merely because it is AI.
Its permissions must be explicitly approved for the purpose, process and identity under which it operates. Two identity models exist, and they should not be confused.
Delegated or user-context AI
Typically operates using the permissions and context of the user it supports.
Process or service-context AI
May use a separately approved application or service identity with deliberately scoped permissions.
Unrestricted backend access is not an acceptable design in either model.
Human oversight
Human oversight should follow consequence, reversibility and organisational policy.
Answering is not the same as executing. As consequence increases, approval, validation, audit and reconciliation should increase with it.
Information
AI supplies information. The person decides what to do with it.
Recommendation
AI recommends, with oversight according to consequence.
Prepared action
AI prepares an action and it waits for approval.
Controlled execution
Automation executes inside explicit authority and limits.
High-consequence action
May require stronger approval, additional controls or prohibition according to customer policy, risk and applicable obligations.
Agent governance
Control the action, not only the prompt.
An agent should not receive unrestricted system access. It should operate through a defined set of approved actions, with an owner and a route to disable it.
- Approved actions
- Approved systems
- Identity
- Role
- Data scope
- Approval
- Spend and action limits
- Retries
- Logging
- Reconciliation
- Owner
- Production status
- Change and version
- Emergency disable owner
Reconciliation and failure
Knowing an action was requested is not the same as knowing it succeeded.
If an agent requests a purchase order, success is not the API call. It is the order, the number, the expected data and the absence of partial failure.
Requested
The action was asked for by an identified initiator.
Executed
The call was made to the target system.
Result returned
A response came back, which is not the same as success.
Business state checked
The record, number and data are confirmed.
Reconciled
Partial failure is identified rather than assumed away.
Failure
AI needs a safe way to fail.
Timeouts, unavailable tools or models, invalid responses, permission denials, business-rule failures and integration errors each need a defined outcome. Uncontrolled repeated business action is not an option.
- Retry
- Fallback
- Ask a human
- Escalate
- Stop
Predictive intelligence
A prediction should support a decision, not disguise uncertainty.
Confidence, drivers, evidence, drift, feedback and model performance are covered in depth on the specialist page rather than duplicated here.
Shared responsibility
Shared responsibility means every material boundary has an owner.
Responsibilities are distinct but connected. Gaps and overlaps need to be made explicit. Microsoft service responsibilities vary by service, so we confirm the current position against Microsoft documentation for the services in your architecture rather than generalising here.
- Customer
- InteliSense
- Microsoft
- ISVs
- CSP
- Identity provider
- Security provider
- Integration supplier
- Managed service provider
- Shared responsibility means every material boundary has an owner
Customer
Business policy, risk appetite, users, business responsibilities, data, access approval, organisational security policy, regulatory interpretation, supplier governance and risk acceptance.
InteliSense
Only what is agreed: security design, configuration, application controls, testing, support access and governance activities.
Microsoft
The relevant responsibilities for its cloud services, which vary by service.
Other suppliers
ISVs, integration suppliers, identity and security providers own their contracted services.
A partner can design and operate controls. The organisation still owns the risk decisions behind them.
High-consequence contexts
The more consequential the service, the clearer the controls need to be.
Multi-agency working should not mean uncontrolled information sharing, and a technical control on its own does not evidence regulatory compliance.
- Sensitive personal information
- Cross-organisation access
- Safeguarding
- Service decisions
- Funding and approval
- Audit
- Organisational boundaries
- One security or regulatory model does not cover every sector
Assurance evidence
Only what can be verified is published.
Technology controls can support compliance. They do not replace organisational responsibility, and a badge is not evidence.
- How InteliSense says security is approached
- Published on this page
Procurement
Security review is often part of the buying decision.
Tell us which areas your procurement or security team needs to assess and we will route it to the right team and share what is approved for disclosure.
- Company details
- Insurance
- Policies
- Data processing
- Architecture
- Subprocessors
- Certifications
- Business continuity
- Security controls
- AI governance
Do not enter passwords, credentials, access tokens, personal information or vulnerability details in this form. Tell us the topic only and we will agree an appropriate route. A published secure vulnerability-reporting route is not yet available, so please request a secure channel without including any detail of the issue itself.
Customer experience of working with InteliSense
What our published evidence does and does not show.
Published customer videos describe their experience of Dynamics delivery with InteliSense in their own words. They are not offered as proof of security, governance, compliance, recovery, support, long-term relationships or security outcomes. For this page, verified organisational assurance evidence is more relevant.
Where governance shows up commercially
Security and governance is mostly a discipline, sometimes an engagement.
Governance is cheaper to design early than to retrofit later.
A discipline inside every implementation
Security context, control design, proof and review sit inside the delivery method rather than beside it.
A governance workstream inside Optimise
Excess access, role complexity, unused accounts, unowned service identities and audit weakness are improvable without a new programme.
A workstream inside Recovery
Uncontrolled administrative access, unclear environments and unknown integrations usually surface during recovery.
A responsibility inside Support
Support access, escalation, change control and periodic review, where those form part of the agreed service.
A standalone Security & Governance Review
Whether this exists as a separately sellable engagement, and on what commercial basis, has not been confirmed. No price, duration or fixed scope is stated here.
Where a review is commercially approved
Outputs it may include.
Not every artefact is produced on every engagement. Depth follows scope and consequence.
- Security context and risk summary
- Identity and access model
- Role and segregation findings
- Privileged-access findings
- Non-human identity register
- Environment access model
- Integration identity and credential findings
- Data-access concerns
- AI and agent control findings
- Control and evidence register
- Exception and residual-risk register
- Recommendations and immediate actions
- A route into Implementation, Optimise or Recovery
When control has already been lost
Uncontrolled admin access, unclear environments, unknown integrations and unowned service accounts usually surface during recovery.
Explore RecoverDesigned early rather than retrofitted
Identity, role design, environment strategy, data, integration and AI governance belong in the transformation, not after it.
Explore TransformAcceleration does not remove control
RAPID accelerates a qualified delivery route. It does not justify bypassing security, testing, access control, validation or approval.
Explore RAPIDGovernance is worth optimising
Excess access, role complexity, unused accounts, manual approval and audit weakness are all improvable without a new programme.
Explore OptimiseOperating the controls day to day
Support access, escalation, change control, problem management and third-party coordination keep the model intact after go-live.
Explore SupportSecuring control of an inherited estate
Partner transition is one of the few moments where every identity, permission and supplier account is examined at once.
Explore Partner Transition
Specialist detail
Platform by platform, and discipline by discipline.
The design principles remain consistent. The platform mechanisms differ, so the depth sits here and on the specialist pages rather than in the executive layer.
What to expect from us
What a customer should be able to hold us to.
These are operating commitments, not certifications. Anything specific to your environment is agreed in writing rather than implied here.
- Access we hold is named, minimised and removable.
- Change is requested, assessed, approved and recorded.
- Data handling is discussed before it is designed.
- AI capability operates inside permissions explicitly approved for its purpose and identity.
- Escalation routes are agreed rather than improvised.
- Responsibility between customer, InteliSense, Microsoft and other suppliers is written down.
- Exceptions are visible, owned and time-bound rather than quietly absorbed.
Governance router
Where would a security conversation start for you?
Four questions, kept at organisational level. The result is a likely starting point rather than a security assessment, and we do not diagnose severity from a form.
Indicative signal
Answer the questions and we will show a likely starting point. This is orientation rather than a security assessment, and we do not diagnose severity from a form. Please keep every answer at organisational level and never include credentials or vulnerability detail.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions we are usually asked.
Security and governance
Trust needs more than a promise.
If security, data, access, governance or AI controls are important to your programme, make them part of the conversation early. Understanding the boundaries before delivery begins is easier than reconstructing them later.