Security

software:

secure

and

compliant.

Access control with roles and permissions.

Role-based access control links permissions to a role rather than to a person. A new employee is assigned a role and, with it, the appropriate access level all at once. When someone leaves, all access is revoked simultaneously. In practice, things go wrong because of exceptions: someone is granted temporary additional permissions and ends up keeping them. A functional setup therefore keeps things simple. One role per user, a permissions matrix that determines what that role can see and do, and roles that belong to a single organization so that data doesn’t leak beyond those boundaries. Plus, a set expiration date for temporary permissions and a periodic review that someone actually carries out. You can see how this works in portals with roles and permissions.

Single sign-on and multi-factor authentication.

With single sign-on, a user logs in once and then has access to all linked applications via protocols such as OAuth or SAML. The benefit isn’t just convenience: account creation and revocation are managed through a single central source, so when an employee leaves, they’re removed from everywhere in a single step instead of having to be removed from eight separate applications. We integrate with the provider you’re already using. Microsoft Entra ID is in production, as are SAML integrations via our own Cube packages for Laravel and SilverStripe, and for organizations using AFAS, we use AFAS as the identity source for portal users.

When it comes to multi-factor authentication, the question isn’t “if,” but “which method.” An authenticator app is free and always works, but it doesn’t work for employees who don’t have a phone with them on the job site. A hardware key is phishing-resistant but incurs a cost per user. Approval via email is the weakest form. An external identity provider offers more control and insight, at a monthly cost. We make that assessment on a per-organization basis, not based on standard recommendations.

Audit trails and logging.

An audit trail records who changed what and when, in a format that cannot be altered retroactively. This is different from logging for error detection, although the two are often confused. Technical logs may be deleted after thirty days. You must retain an audit trail for as long as your accountability obligation remains in effect, and it must be readable by someone without a technical background.

Such a trail only becomes useful if it also records why something was changed. In one of the platforms we’re building, a user can only modify a critical field after unlocking it, by selecting a required reason from a fixed list and attaching supporting documentation. This takes the user ten seconds and saves an afternoon’s worth of research during an audit.

Compliance and audit dashboards.

A compliance dashboard shows whether you’re meeting your own policies: which controls are active, which are overdue, which risks remain open, and who is responsible. The value lies in the moment you consult it. Without a dashboard, an audit begins with weeks of data collection from disparate systems and spreadsheets. With a dashboard, it’s just an export.

Authorization in portals.

In a portal where multiple organizations come together, authorization is at the heart of the design. A supplier sees only their own orders and no one else’s. A dealer sees only their own margins. This may seem obvious, but it is the most common source of data breaches in portals: a user accessing another party’s data via a modified URL or a direct API call. Authorization should therefore be handled on the back end and not in what the interface displays.

Data minimization, encryption, and pseudonymization.

Data you don’t store cannot be leaked. Data minimization starts with asking which fields your process truly needs—and that is a design decision. Whatever you do store must be encrypted both in transit and at rest. Pseudonymize personal data that you use solely for analysis, so that it can no longer be traced back to an individual. For healthcare applications, the regulatory framework applies; see NEN 7510 for healthcare.

AI Governance and AI Security.

As soon as an application contains a large language model or an AI agent, additional questions arise: what data goes to the model, who is authorized to view which responses, and how do you document what the system has decided? The EU AI Act sets requirements for transparency and human oversight, which translate into concrete functionality: logging of prompts and responses, a clear definition of what data the model is allowed to see, and a human review step for decisions with consequences. More on this under AI security and governance.