SOFSEK

Access governance and segregation of duties

Know who can do what, across every application you run.

SOFSEK pulls users, roles and entitlements from your connected systems and resolves them into one access model. It tests that model against your segregation of duties policies, tracks every conflict to closure and proves it to your auditor.

Download the PDF overview See how it works
Two operators at a control console in a 1950s test facility control room, one watching dials, one pointing at an indicator panel
Someone has always needed to see who is touching what. NASA, public domain.
One access modelNormalised from every connected system
Policy engineSeverities, controls and governed exceptions
Closed loopEvery finding mitigated, accepted or resolved
Audit readyPacks mapped to regulatory frameworks
A heavy chain and open iron padlock on a cell door, with a small modern padlock and key beside it
A lock only works if you know who holds the key. Historic American Buildings Survey, public domain.

The problem

Every system looks fine alone. The conflict only shows when you add them up.

People change jobs, cover for colleagues and collect roles. One person ends up able to raise a payment and approve it, or create a supplier and pay them. No single application sees that.

  • Spreadsheets go staleAn access review done once a year describes a company that no longer exists.
  • Roles hide dutiesA role name tells you little about the actions it really grants.
  • Auditors want evidenceSaying it is under control is not enough. You need the history to show it.

One cross-application access model

Many systems in. One picture out.

SOFSEK ingests users, roles and entitlements from each connected application and normalises them into a single model of users, roles, actions, duties and groups. Delegations and temporary cover belong in it too, so the picture matches how your organisation really works.

How SOFSEK turns connected systems into one governed access model Four source types feed an access model made of users, roles, actions, duties, groups and delegations. The model feeds a policy engine, which produces violations, a risk heatmap and audit packs. CONNECTED SYSTEMS ERP exports CSV files Application APIs Manual intake Access model One normalised view Users Roles Actions Duties Groups Delegations Granted-by lineage on every effective duty Policyengine Rules, severityand controls Violations Heatmap Audit packs
Sources vary. The model does not. Every downstream test runs against the same normalised picture.

Policy engine

Write the rule once. Test every person against it.

Define which duties must never sit together and how serious the conflict is. Each scan looks at a person's combined access across all their roles and raises a violation when two conflicting duties meet.

  • Cross-role detectionThe conflict is found even when no single role is at fault.
  • Severity on every ruleCritical findings rise above the noise.
  • Mitigating controlsRecord the control that makes a conflict tolerable, and who owns it.
  • Governed exceptionsAn exception is never open ended. It has an owner and an expiry date.
A segregation of duties conflict A user holds two roles. One grants the duty to create a supplier and the other grants the duty to approve payments. The policy flags the pair as a critical conflict. One person Purchasing Finance Create supplier Approve payment Critical conflict Raised, owned, tracked
An illustrative rule. Your own rules and severities replace it.

Violations tracker and remediation workspace

Every finding has an owner and an end.

A violation has a life. It is detected, assigned, then resolved, mitigated or accepted as an exception. When an exception lapses, the finding returns to view on its own. The history stays with it for the auditor.

Violation lifecycle A violation moves from detected to assigned. From there it can be resolved, mitigated by a control, or accepted as an exception with an expiry date. All three end in closed. A lapsed exception returns to assigned. Detected Assigned Resolved Mitigated Acceptedwith expiry Closed Expiry lapses, finding returns
A large bank vault door with two hand wheels on a central shaft
Two wheels, two hands. Dual control is an old idea. Bowery Savings Bank, 1923, public domain.

Risk heatmap

Weighted by the value that actually flows through the conflict.

A conflict on a duty that moves a little money is not the same as one that moves a lot. The heatmap puts the financial exposure on the map, so you fix the expensive problems first and can show why.

Illustrative risk heatmap A grid of processes against severity. Darker cells carry more financial exposure. The payables and treasury processes show the highest exposure. LowMediumHighCritical PayablesTreasuryPayrollProcurementSales Darker means more value flowing through the conflict
Illustrative layout with sample values. Your own processes and exposure fill the grid.

Fix in order of cost

Rank conflicts by exposure, not by how many there are.

Filter to the owner

Slice by company, role or person so each process owner sees their own part.

Three technicians working at a wall of dials and chart recorders in a reactor control room
Every dial has someone who knows how to read it. NASA, public domain.

Operational bottleneck dashboard

Find the places where one person is the only path.

Segregation of duties is not only about too much access. It is also about too little cover. SOFSEK shows where a single person holds a duty nobody else can perform, so a holiday or a resignation does not stop the business.

Single point of dependency Five duties all depend on one person. Oneperson Month-end close Supplier setup Payment release Price changes Stock adjustments Single path
Illustrative. A finding can be excluded from the analysis when the dependency is intended.

Scheduled ingestion and reconciliation

Fresh data, with the changes made visible.

Load roles, users and assignments through a column-to-field mapping engine, with no scripting. Each run is reconciled against the one before, so you see the variance and not just the snapshot. Requests that arrive from people rather than systems wait in an intake queue.

Ingestion pipeline A scheduled run loads source data, maps columns to fields, reconciles against the previous run and produces a variance of added, removed and changed records. An intake queue handles manual requests. Scheduled runSource data Field mappingColumn to field ReconcileAgainst theprevious run Added Removed Changed Variancedashboard Intake queue

Sandbox simulation

Model the change before you grant it.

Try a fix before you make it. Shadow Run replays the detection engine against a proposed change such as a new role, a revocation or a delegation. It shows what the change clears and what it creates. Nothing is written to your applications.

Sandbox simulation Current access and a proposed change enter an isolated sandbox. The detection engine replays and compares the result with production. The outcome is cleared conflicts and new conflicts. The change is then granted or declined. Current accessLive model Proposed changeRole, revoke, delegate ISOLATED SANDBOX Shadow RunDetection engine replayedand compared side by side Conflicts clearedWhat the change fixes Conflicts createdCaught before granting Grant ordecline

Audit and provisioning

Proof on demand, not in a scramble.

Audit packs

Generate a pack mapped to the regulatory frameworks you report against. Hand it to the auditor with the history already inside.

Provisioning gateway log

See each access request as it passed through the gateway, so approvals and grants can be traced from request to result.

Full lineage

For every effective duty, see which role or delegation brought it, and who granted it.

Built on the Integrytas platform

Security that is engineered in, not bolted on.

Multi-tenant

Each customer runs in its own tenant with its own data boundary and its own URL.

Signed licensing

Module entitlement is a cryptographically signed token verified at the gateway, not a flag in a database.

Row-level security

Every table is protected by policies enforced in the database itself.

Audit trail

Every change records who, what and when. An administrator acting on someone's behalf is recorded as themselves.

Role-based access

Fine-grained page and action permissions per role, with multi-level sign-off where a change needs a second pair of eyes.

Three locales

US English, UK English and Mexican Spanish out of the box, with a translation editor for more.

Next step

See your own conflicts, not a demo.

Start with a snapshot of your own access. SOFSEK takes it from there. Take the PDF overview to your risk, finance or audit lead and see what they make of it.

Download the PDF overview
Photo credits. All photographs are in the public domain, sourced from Wikimedia Commons.

Diagrams use illustrative data. SOFSEK is a product of IntegrytasGroup.