Otukan gives a fleet review two kinds of operational evidence: an audit trail of administrator actions and a report of the configuration state each device has applied. The trail records who changed a policy, assigned an app or ran a remote command, when, and what changed. The state report shows which policy each device has applied, its OS version and when it last checked in, with drift flagged. Auditors read both through their own read-only role. Otukan reports evidence; whether that evidence meets a given standard is your reviewers’ decision. What a public institution should ask for as procurement evidence is covered on government mobile device management.
Audit events
Otukan logs the actions that change what a device can do or who can reach it.
| Event | What is recorded |
|---|---|
| Administrator sign-in | Person, role, time and outcome |
| Policy change | Policy, groups affected, settings before and after, person and time |
| App assignment or removal | App, version, groups, person and time |
| Remote command | Command, target device, requester, time and result |
| Role or permission change | Account changed, rights before and after, who approved it |
| Enrolment settings change | Enrolment profile or group rule changed, person and time |
| Supplier support session | Case, approver, start and end time, actions taken |
Each entry names a person, not a shared account. Where a break-glass account is used, the entry is flagged so a reviewer sees it first.
Change history
Policy edits keep their full history. A reviewer can open any policy, see each version in order and see who approved the move from one version to the next. The history can be filtered by policy, device group or administrator, which turns a question such as “what changed on the warehouse scanners last quarter” into a short search.
Reporting scope
Otukan keeps two things apart: what devices report and what that means for your rules.
Configuration state
Every managed device reports what it has applied: its policy, its managed apps, its OS version and its last check-in. Otukan compares that with the policy assigned to the device’s group and flags any difference. A device that has not checked in is listed separately, because silence is itself something a reviewer should see.
What a device can report depends on its platform and management mode. A corporate-owned device reveals more than a personally owned one, and Android and Apple devices each report their own set of fields. Otukan labels every field by platform and mode.
Compliance conclusions
A standard or regulation asks whether controls are adequate. That judgement depends on your rules, your risk decisions and the exceptions you approved. Otukan supplies the records a reviewer needs to reach it, traceable to the device and the moment. It does not stamp a verdict on your fleet.
| Otukan reports | Your reviewers decide |
|---|---|
| Passcode policy applied on a device | Whether that passcode rule meets your standard |
| Device on an older OS version | Whether that version is acceptable, and until when |
| Policy drift since a given date | Whether the drift is a finding or an approved exception |
Governance
Audit records only help if the right people can read them, for as long as reviews need them.
- Access. Auditors receive read-only accounts, scoped to the device groups they examine. They can read configuration, state and logs, but cannot edit policy or run commands.
- Retention. You agree how long audit logs and device state history are kept, and who may change that period.
- Export. Logs and state reports are exported on request for your own evidence archive.
- Supplier visibility. Otukan support staff reach your fleet only for an approved case and period, and their sessions sit in the same log as your own administrators’ sessions.
A review pack
When a review opens, Otukan helps you assemble the same set of records each time, so reviews stay comparable from one period to the next:
- the change history of every policy in scope for the review period;
- the current drift list and the devices that have not checked in;
- remote commands run in the period, with requester and result;
- role and permission changes, and any break-glass use;
- supplier support sessions, with the approver of each.
Because the pack is built from the audit log itself rather than from notes written afterwards, each line in it can be traced to an entry a reviewer can open.
Where fleet data is hosted and how supplier access is approved is covered on MDM data sovereignty. The parent overview is mobile device management.