Skip to main content

    Suite 07 of 7

    Trust & Governance Suite

    Make trust part of the customer operating model.

    Connect identity, access, auditability, privacy, consent, data-residency controls and AI governance to the management of customer relationships.

    Governance is not an afterthought. It is a foundational dimension of enterprise CRM.

    See the Control Plane
    The challenge

    What trust & governance leaders are up against

    The Trust & Governance Suite puts controls in the path of every customer-record action — who signed in, what they were allowed to do, which consent applied, and what was recorded for review.

    • Access wider than it should be

      CRM access is broader than needed and hard to evidence for auditors.

    • Privacy handled outside the CRM

      Consent and data-subject requests are handled outside the system that holds the data.

    • Unclear data location rules

      Where data is held and which transfer rules apply are unclear per tenant.

    • AI switched on without a policy

      AI features are enabled without a usage policy or review of their output.

    Signature view

    The Control Plane

    Every customer-record action crosses four control bands — identity, authorisation, the record itself and evidence. Consent and regional settings travel with the record; audit and data-subject responses read from the same trail.

    • Activity
    • Decision
    • Record
    • Outcome

    1. 01 ActivityIdentity

      Sign in

      Single sign-on with OIDC or SAML, under multi-factor authentication policies.

      Who acts, record
      Owned by
      Security administrator sets the policy
      Record
      Sign-in event
      Capability: Identity & Access

    2. 02 DecisionIdentity

      Step-up needed?

      Sensitive actions can require step-up authentication.

      Who acts, record and exceptions
      Decided by
      Policy set by the security administrator
      If it goes wrong
      Step-up fails: the action is refused and recorded.
      Capability: Identity & Access

    3. 03 ActivityAuthorisation

      Role and field check

      Roles and field permissions control who can view and change customer data.

      Who acts, record
      Owned by
      Security administrator
      Record
      Access decision
      Capability: Identity & Access

    4. 04 DecisionAuthorisation

      Different approver?

      Approval rules can require a different person to approve.

      Who acts, record and exceptions
      Decided by
      Approval rules set by administrators
      If it goes wrong
      Same person: the approval is refused.
      Capability: Audit & Compliance

    5. 05 ActivityRecord & data

      Act on the record

      The change is made on the customer record.

      Who acts, record
      Owned by
      The user
      Record
      Changed record
      Capability: Privacy & Consent

    6. 06 RecordRecord & data

      Consent and region

      Consent preferences travel with the record. The deployment region is selected where available, with details agreed per contract.

      Who acts, record
      Owned by
      Data protection officer · tenant administrator
      Record
      Consent preferences; regional data settings
      Capability: Data Residency

    7. 07 RecordEvidence

      Audit trail

      User actions and approvals are recorded for later review.

      Who acts, record
      Owned by
      Auditor reviews
      Record
      Audit entries
      Capability: Audit & Compliance

    8. 08 OutcomeEvidence

      Audit or request answered

      Data-subject requests and audit questions are answered from the same records and trail.

      Who acts, record
      Owned by
      Data protection officer · auditor
      Record
      Response with its evidence
      Capability: Privacy & Consent
    Illustration of controls around a customer-record action — not a product screen, and not a statement of certification or of where data is held.
    5 Capabilities

    Inside the Trust & Governance Suite

    Each capability: its purpose, what it covers, who decides, the records it keeps and how exceptions are handled. Functions included in a deployment are agreed during solution design.

    Capability 1 of 5

    Identity & Access

    Control who can sign in and what they can see and change.

    Previously listed as

    New capability in the Suite structure.

    What it covers

    • Single sign-on with OIDC or SAML
    • Multi-factor authentication policies
    • Step-up authentication for sensitive actions
    • Role and field permissions

    Who decides

    The security administrator sets sign-in policies, roles and field permissions.

    Records it keeps

    • Sign-in events
    • Role and permission changes

    Exceptions

    • A failed step-up refuses the action and records it.

    Capability 2 of 5

    Audit & Compliance

    Record user actions and approvals for later review.

    Supports audit and compliance activities; each organisation remains responsible for its own compliance.

    Previously listed as

    New capability in the Suite structure.

    What it covers

    • Audit trail of user actions and approvals
    • Approval rules that can require a different person to approve

    Who decides

    Administrators configure approval rules. Auditors review the trail.

    Records it keeps

    • Audit entries
    • Approval records

    Exceptions

    • An approval by the same person who requested it is refused.

    Capability 4 of 5

    Data Residency

    Make regional data controls explicit for each deployment.

    The deployment region can be selected where available; details are agreed per contract.

    Previously listed as

    New capability in the Suite structure.

    What it covers

    • Regional data controls
    • Cross-border rules

    Who decides

    The tenant administrator configures regional settings; commitments are agreed in the contract.

    Records it keeps

    • Regional data settings

    Exceptions

    • A transfer outside the configured rules is refused.

    Capability 5 of 5

    AI Governance

    Decide where AI assistance is used and review its output.

    Previously listed as

    New capability in the Suite structure.

    What it covers

    • AI usage policies
    • Review of AI output
    • Information about the models in use

    Who decides

    The AI governance owner sets the usage policy. Administrators control where AI assistance is enabled.

    Records it keeps

    • AI usage policy versions
    • Output reviews

    Exceptions

    • AI assistance stays off where the policy does not allow it.
    Accountability

    Escalation, exceptions and the people who decide

    “Controls sit in the path of the work, and every control leaves evidence.”

    • Authentication

      Trigger: Step-up fails

      Who acts: Security administrator reviews

      The action is refused and recorded.

    • Approval

      Trigger: Requester tries to approve their own request

      Who acts: Approval rules

      A different person must approve.

    • Data-subject request

      Trigger: Customer asks for access or erasure

      Who acts: Data protection officer

      The request and its response are recorded.

    • AI use

      Trigger: AI assistance requested outside policy

      Who acts: AI governance owner

      Stays off until the policy allows it.

    AI and automation, by mode

    • Rules and automation

      Policy-driven controls configured by administrators.

      • — Sign-in and step-up policies
      • — Approval rules
      • — Retention policies

    • AI assistance

      Governed here, used in other Suites.

      • — Where AI assistance is enabled
      • — How its output is reviewed

    • Not offered

      Decisions that stay with people.

      • — Granting access
      • — Answering a data-subject request
      • — Approving an AI use
    Performance

    What teams can follow

    Measures teams can follow where configured. Names only: targets and results belong to each organisation.

    • Users by role

      From Identity & Access

    • Permission changes

      From Identity & Access

    • Approvals by outcome

      From Audit & Compliance

    • Data-subject requests by status

      From Privacy & Consent

    • Consent coverage of active audiences

      From Privacy & Consent

    • AI output reviews

      From AI Governance

    Standards and frameworks

    Context, not certification

    How the Suite relates to recognised standards. This describes alignment of practice; conformity and certification belong to each organisation.

    • ISO/IEC 27001

      Context: the Suite is designed to help customers address information-security controls for customer data; no certification is stated here.

    • ISO/IEC 27701

      Context for privacy information management of customer records.

    • GDPR · UAE PDPL · KSA PDPL

      Designed to help customers address consent, data-subject rights and retention obligations; each organisation remains responsible for its compliance.

    • ISO/IEC 42001 · NIST AI RMF

      Context for AI usage policy and output review.

    Operating model

    Five controls, one customer record

    Each control has an owner and produces its own evidence.

    1. Identity

      Who is this?

      Accountable: Security administrator

    2. Permission

      What may they do?

      Accountable: Security administrator

    3. Privacy

      What did the customer agree to?

      Accountable: Data protection officer

    4. Location

      Where is the data held, and may it move?

      Accountable: Tenant administrator

    5. AI

      Where may AI assist, and who reviews it?

      Accountable: AI governance owner

    Boundaries

    Where the Suite ends, and who takes over

    iShield Connect owns CRM and customer engagement. Each other platform keeps its own responsibility.

    • iShield Connect

      The Trust & Governance Suite owns

      Sign-in policies, roles and field permissions, approval rules, the audit trail, consent, data-subject requests, regional settings and AI usage policy for customer records.

    • iShieldGRCExplore iShieldGRC

      Owns

      Where an organisation runs iShieldGRC, enterprise governance, risk, compliance and privacy programmes sit there; Connect supplies the customer-record controls and evidence.

    • iShield NexusExplore iShield Nexus

      Owns

      Security operations across the technology estate belong to iShield Nexus.

    • iShield LinkExplore iShield Link

      Owns

      Identity providers and enterprise systems are connected through iShield Link where implemented and configured.

    These boundaries describe how responsibilities are intended to divide between the platforms. Integration depth depends on how they are implemented and configured.

    The seven iShield Connect Suites

    See the Trust & Governance Suite with your own customer journeys.

    Request a demo and we will walk through the Suite against your processes, roles and boundaries.

    Your privacy choices

    We use strictly necessary storage to run this website. With your permission we also use first-party analytics to understand which pages are useful. Analytics stays off unless you choose "Accept all" or turn it on in "Manage". You can change your choice at any time from "Cookie settings" in the footer. See our Privacy Policy.