Security and traceability
This page summarizes Mawidabp's security model: how users authenticate, how permissions are controlled, and what is logged automatically to audit the use of the system itself. The operational configuration (user onboarding, profile definition, identity integrations) lives in the specific pages; here we describe the concepts.
Authentication
Mawidabp supports two authentication modes:
- Local: users and passwords managed inside the application.
- Integrated with a corporate identity provider: Microsoft Entra ID, Google Workspace, or LDAP / Active Directory.
When the instance is integrated, the sign-in flow redirects to the provider and the password is managed by the provider, not by Mawidabp. User onboarding and offboarding are also synced with the provider's groups.
MFA (second factor)
Mawidabp supports TOTP-based MFA. When the organization requires MFA, on sign-in the user must enroll an authenticator app (Google Authenticator, Microsoft Authenticator, 1Password, or another) and enter the six-digit code on each sign-in. Enrollment happens the first time the user signs in after MFA is enabled.
If an external provider with its own MFA is used, the second factor is enforced by the provider.
Profiles and privileges
Information access is controlled by profiles. A profile has a type (which determines the functional role) and a combination of privileges per module.
Profile types
- Audit manager
- Supervisor
- Senior auditor
- Auditor
- PAI (user and profile administration)
- Auditee
A single user can have different profiles in different organizations.
Privileges
For each module, a profile can have any combination of:
- Read
- Modify
- Delete
- Approve
When the instance is integrated with AD/Entra ID, each profile corresponds to a group in the directory: assigning a user to the group in AD automatically inherits the Mawidabp profile.
The configuration detail is in Users and profiles.
Traceability: the system log
Every relevant action is recorded in the system log: what changed, who changed it, when, and the previous value when applicable. The log covers key entities such as:
- Organizations, units, and configurations.
- Users, profiles, and privileges.
- Plans, reviews, and workflows.
- Findings (status changes, comments, attachments).
- Working papers.
This information lets you reconstruct the full history of any review.
Sign-in records
Every sign-in attempt is logged with date, time, user, IP, and result. Helps detect anomalous accesses and see each user's presence history.
Database logs
In addition to the application log, the PostgreSQL engine can produce additional logs through its WAL records. These logs are useful when you need to investigate specific operations in depth or meet external audit requirements.
Security reports
The Administration module includes Security reports with information ready to use by the IT security area:
- Active and inactive users.
- Assigned profiles and privileges.
- Recent accesses per user.
- Sensitive changes recorded by the log.
Encryption and storage
Information is stored encrypted in the centralized repository. Access to the system is always over HTTPS. When automatic backups are configured (see Backup and restore), files can be stored in S3 or another compatible destination.