Before acting
Identify the person and the organization, verify the role and define which information and actions are available.
Identity and permissionsCatalisa / GovernanceTrust has
Trust has
structure.
Who can act. What needs review. How to understand what happened. Governance connects these answers to the operation.
Explore the responsibilities ↓More clarity to act.
More context to respond.
More context to respond.
The foundation provides mechanisms.
Operations set the direction.
Governance is built into the design of every journey: in access, rules, review and the records that help reconstruct the work.
The platform connects these capabilities. Each organization defines its policy, configures the controls and validates whether they meet the requirements of the context in which it will operate.
Before, during and afterAn action needs
An action needs
make sense
at every moment.
When the action requires review
Define what requires someone else, at which step, and with what authority. Approval design is part of the journey.
Access policyAfter it happens
Link the action to the available records, the change made and the rule that guided the outcome.
History and evidenceTwo people. Different responsibilities.A request doesn't have to
A request doesn't have to
be the approval itself.
Experience the separation between
who requests and who reviews.
A look at the four-eyes principlePrepare.
Prepare.
Check it out.
Decide.
IAM documents a second-person review policy for sensitive access changes covered by this control.
When the organization's policy is enabled, the change creates a request. The review falls to another authorized person in the same organization.
This is a local, illustrative example. It does not change permissions. The actual scope depends on the activated policy and the actions covered in IAM.
See the documented scopeEXAMPLE / SENSITIVE ACCESS CHANGERequest not yet created
Grant a role
of sensitive access.
One person requests. Another authorized person reviews, within the same organization.
ApplicantPrepares the request
ReviewerChecks and decides
Start with person A and prepare the request.
When the question comes: what happened?The history needs
The history needs
help tell the story.
A change gains context when you can link who acted, what changed and which reference was used.
ILLUSTRATIVE VIEW / NO REAL DATAOne change.
One change.
More than one
question.
Records come from the responsible capabilities. The example organizes the questions an investigation needs to answer.
Person, system and organization
Identity context travels with the action according to the mechanism used.
Appeal and change
The history can show the previous state and what remained afterward.
Reference and version
An evaluation can be linked to the policy version that was published.
Events actually recorded
The trail depends on the events each capability publishes. Coverage needs to be verified.
Audit Trail is in Beta. Declared retention does not mean automatic deletion; configuration, collection, and operational procedures must be active. Verifiable trail integrity has documented limits.
Check coverage and limitsGovernance keeps pace
the type of work.
An overview of accessPeople, roles
People, roles
and statuses need to
be understandable.
An interface helps the team check who takes part in the operation and under what conditions. Permissions are still enforced by the responsible capability.
Reference interface from the Banking guide: prototype with sample data. The screen does not prove that all the flows shown are available.
Explore the banking platformConsole / People and accessEnlarge ↗
Capabilities behind the controlsEach mechanism has
Each mechanism has
a role and a stage.
Explore the capability's purpose
and check the limits before integrating.
IAMProduction↗API KeysProduction↗Decision EngineProduction↗Audit TrailBeta↗BiometricsAlpha↗Feature FlagsProduction↗
Identity and access
Recognize the person, the organization and the permissions that come with the action.
System-to-system access
Define what an integration can view or do.
Rules with references
Identify the policy version used in an assessment.
Change history
View published events, with context on what changed.
Identity verification
Link the assessment and its evidence to the verification session.
Step-by-step change
Control a feature's exposure based on the product configuration.
To assess clearlyTrust, too
Trust, too
is understanding the scope.
Does having a trail mean logging everything?
No. The trail depends on the events published by the capabilities. Check which actions are covered, whether collection is enabled and which records are available in your composition.
Does the four-eyes principle apply to every action?
The mechanism documented in IAM covers sensitive access changes defined by the policy, when enabled. Approval of payments, documents or other actions requires its own design and validation.
Can an agent use everything just because it received an instruction?
Instructions guide behavior. Access to tools and actions needs its own controls, configured for the role and context in which the agent participates.
Does setting a retention period delete the records right away?
No. The Audit Trail documentation distinguishes the declared policy from the execution of the deletion procedure. Operations must configure and monitor this process, taking the documented limits into account.
Do these mechanisms guarantee compliance on their own?
They provide resources for designing controls. Policy, configuration, coverage, operation and sufficiency assessment depend on the organization's context. They are not equivalent to an automatic certification.
Where should the assessment start?
Choose a journey. Identify who is involved, what information they use, which actions require review and which records need to be available. Then compare those needs with the stage and limits of the capabilities you've chosen.
Autonomy that meets accountabilityBuild the next step.