Security without the jargon.

A front door is not planned only after moving into a house. Software should likewise consider protection needs, sensitive data, access and possible failures in its requirements and architecture.

We clarify protection needs and risks before implementation, document decisions and review safeguards throughout development.

A new flat is handed over with its front door closed. Nobody should have to find numerous switches before a system is reasonably protected.

New accounts receive only necessary rights, risky functions start disabled and safeguards do not depend on extra knowledge.

Before a hike, people check weather, route and escape options. Software is examined in the same way: what needs protection, who might attack and what a failure could cause.

Realistic risks become concrete requirements, tests and priorities rather than an unfocused list of theoretical dangers.

Someone collecting a parcel does not need to reveal their whole life story. Systems should ask only for necessary data, protect it appropriately and use privacy-friendly defaults.

Purpose, retention, permissions and deletion are defined during planning rather than added later.

A hotel guest receives a key to their room—not every room, the kitchen and the office. Users and applications should likewise access only what they need.

Roles stay small and understandable. Additional rights are granted deliberately, reviewed regularly and removed again.

An important room may require both a key and a personal code. If one factor is stolen, the attacker still lacks the second proof.

Sensitive accounts and administrative access are protected with an independent second factor.

A festival wristband allows entry, but not automatic backstage access. More sensitive areas require another check of who wants access and whether it makes sense now.

Identity, device, role and context are considered together; a signed-in user does not automatically receive unlimited trust.

Like a sealed letter, encryption protects the contents. Someone observing transport or finding a storage device should not be able to read it without the key.

Depending on the protection need, data is encrypted in transit and at rest, with keys managed separately and under control.

Even a good bicycle needs regular checks. Software weaknesses are monitored, prioritised by risk and addressed with updates or other measures.

Dependencies, updates and reported weaknesses are tracked, with a clear response path for critical issues.

Like a logbook, the system shows more than the current state. It also records who added, confirmed or changed something and when. Earlier entries do not disappear unnoticed.

Important actions receive an immutable or specially protected change history. Access to the log is restricted and retention is planned for the purpose.

Instead of files called “final_new_2”, there is one clear current state. A change creates a new version without silently overwriting the previous one.

Versions record time, origin and responsibility. Authorised people can review differences and restore an earlier state when needed.

A copy in the same folder is not yet a resilient backup. A good backup is protected, created regularly and can actually be restored when needed.

Backup frequency, separate storage, access protection and restore tests are planned according to the importance of the data.

As with a fire alarm, responsibilities, first steps and communication routes should be known beforehand. This helps contain, investigate and learn from an incident.

Logging, alert paths, recovery and reporting processes are prepared in proportion to risk and reviewed regularly.

A bicycle is only as reliable as its parts. Software uses libraries, services and infrastructure from other providers, so their origin and maintenance matter too.

Important dependencies are documented, updated and checked for known risks; unnecessary or unclear components are avoided.

The GDPR concerns information relating to people. In simple terms: there needs to be a clear purpose, a suitable legal basis, as little data as necessary and appropriate protection.

We consider data flows, purpose, rights, retention and deletion during planning. The controller remains responsible for assessing whether a specific processing activity is lawful.

NIS2 requires organisations in scope to manage cybersecurity risks systematically and report significant incidents. It does not automatically apply to every small company or software project.

Where NIS2 may be relevant, we plan for risk analysis, access protection, supply chains, vulnerability handling, recovery and incident processes. Applicability is assessed for each organisation.

The CRA covers many products with digital elements. Manufacturers must address security in planning, development and maintenance, with vulnerability or incident reporting where required.

For products in scope, secure defaults, documented components, update capability and a planned way to handle vulnerabilities become part of the product concept.

AI that sorts personal notes is not treated like AI that influences education, employment or medical care. The AI Act therefore distinguishes systems by risk and purpose.

AI functions are made visible, limitations are documented and human oversight is planned where decisions have consequences. Classification is assessed for the specific use.

Like a digital identity document, a European wallet is intended to provide selected credentials securely and under user control. People should see who requests what and for which purpose.

For identity and trust functions, we consider selective disclosure, understandable consent and interoperable interfaces—without claiming official conformity.

The DSA does not apply to every website. It mainly regulates services that host or mediate third-party content or offers, with transparency and illegal-content processes depending on their role.

For platform functions, we clarify the service’s actual role early and which reporting, transparency or moderation processes need technical support.