Information Security Policy

Version 1.0 — As of: March 2026

CONPORT Services GmbH
Alte Benninghofer Str. 24
44263 Dortmund, Germany
Managing Director: Benjamin Schowe

§ 1 Purpose and Scope

This Information Security Policy establishes the binding principles and requirements for protecting the information assets of CONPORT Services GmbH and the customer data processed on the SaaS platform "Aldric".

The objective is to protect the confidentiality, integrity, and availability of all processed information — regardless of whether it exists in digital or physical form.

This policy applies to:

• all employees of CONPORT Services GmbH
• external contractors, consultants, and service providers with access to systems or data
• all IT systems, applications, and infrastructure components operated as part of the Aldric platform
• data of all tenants using the Aldric platform

§ 2 Information Security Objectives

2.1 CIA Triad

• Confidentiality: Information is accessible only to authorized persons. Tenant data is strictly isolated from one another. Unauthorized access is prevented through technical and organizational measures.
• Integrity: Information is complete, accurate, and unaltered. Manipulation is detected and documented through audit logging with hash chains. Inputs are validated at the API level.
• Availability: Systems and data are available to authorized users as agreed. Downtime is minimized; availability targets are defined in the SLA.

2.2 Compliance Objectives

• Compliance with the General Data Protection Regulation (GDPR / Art. 32)
• Adherence to relevant national and international security standards
• Fulfillment of contractual security commitments to customers (see DPA)
• Achievement of the availability targets defined in the SLA

§ 3 Organization of Information Security

3.1 Responsibilities

• Management: The management (Benjamin Schowe) bears overall responsibility for information security and provides the necessary resources.
• Information Security Officer (ISO): The management designates an Information Security Officer who coordinates the implementation of this policy, assesses security incidents, and serves as the central point of contact for security matters.
• All employees: Every employee is obliged to comply with this policy, report security incidents without delay, and participate in training measures.

3.2 Annual Training

All employees and relevant external contractors participate in an information security training at least once a year. New employees receive a security briefing as part of their onboarding (§ 13).

§ 4 Access Control

4.1 Role-Based Access Control (RBAC)

The Aldric platform implements fine-grained role-based access control at three levels:

• Module level: Access to individual compliance modules (e.g., DPIA, DPA, Audit)
• Function level: Read, write, approve, export within a module
• Record level: Access to individual records based on role and responsibility

4.2 Authentication

• Authentication is handled exclusively via Keycloak (OpenID Connect / JWT)
• Single Sign-On (SSO) is supported
• Multi-Factor Authentication (MFA) is strongly recommended for administrator accounts and can be mandated per tenant
• Token lifetimes and session timeouts are configurable
• Brute-force protection with automatic rate limiting is active

4.3 Principle of Least Privilege

Access rights are granted according to the principle of least privilege. Users receive only the permissions required for their specific tasks.

4.4 Regular Access Reviews

Permissions are reviewed quarterly. No longer needed access rights are revoked without delay. Upon the departure of employees or contractors, all access rights are deactivated on their last working day.

§ 5 Data Isolation and Tenant Separation

5.1 Row-Level Security (RLS)

Tenant separation is technically enforced at the database level through PostgreSQL Row-Level Security (RLS). Every table contains a tenant_id, and all database queries are automatically filtered to the respective tenant by RLS policies — independently of application logic.

5.2 JWT-Based Tenant Identification

A user's tenant_id is derived exclusively from the verified JWT token issued by Keycloak. Manipulation through client-side requests is technically excluded — the application does not accept any tenant-related parameters from the request body or URL.

5.3 Cross-Tenant Protection

Cross-tenant data access is technically prevented through the combination of RLS, JWT validation, and RBAC. Even in the event of misconfiguration at the application level, the database layer prevents any disclosure of other tenants' data.

§ 6 Encryption

6.1 Data in Transit

• All connections between clients and the platform are encrypted using TLS 1.2 or higher
• HTTP connections are redirected to HTTPS; insecure protocols are disabled
• All internal service-to-service connections (including database connections) are encrypted

6.2 Data at Rest

• Files and objects are stored encrypted in MinIO (S3-compatible storage)
• Database backups are stored in encrypted form
• Passwords are hashed using bcrypt and are never stored in plaintext

6.3 Key Management

Cryptographic keys are stored securely and rotated regularly. Expiry and rotation cycles are documented.

§ 7 Network Security

• Firewall rules: Only necessary ports and protocols are open; unused services are disabled
• Network segmentation: Production, testing, and development environments are separated at the network level
• Intrusion detection: Anomalies in network traffic are detected and reported
• DDoS protection: Protective measures against distributed denial-of-service attacks are active
• Rate limiting: API endpoints are protected against abuse through rate limiting
• Administrative access: SSH access to production systems is exclusively through SSH key authentication; password login is disabled

§ 8 Logging and Monitoring

8.1 Audit Logging

The platform comprehensively logs all security-relevant actions, including:

• Logins and failed authentication attempts
• Access to and modifications of security-relevant records
• Administrative actions (role assignments, configuration changes)
• Exports and data downloads

8.2 Integrity Protection via Hash Chains

Audit log entries are protected against retroactive manipulation through chained hashes (hash chains). Each log entry contains the hash of its predecessor, allowing gaps or alterations in the log to be reliably detected.

8.3 Log Retention and Monitoring

• Logs are retained for a minimum of 90 days
• Security-relevant events are automatically detected and trigger alerts
• Critical system components are continuously monitored (monitoring & alerting)

§ 9 Data Backup

• Automated backups: Daily automated backups of all production data
• Encrypted storage: Backups are stored encrypted and separated from the production system
• Retention periods: Daily backups for 30 days, monthly backups for 12 months
• Restore testing: Backup restorations are tested and documented on a regular basis
• RTO/RPO: Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are bindingly defined in the SLA
• Point-in-time recovery: Point-in-time recovery is available for the database

§ 10 Vulnerability Management

10.1 Patch Management

• Dependencies (libraries, frameworks, OS packages) are updated regularly
• Critical vulnerabilities (CVSS ≥ 9.0) are patched within 72 hours of disclosure
• High-severity vulnerabilities (CVSS 7.0–8.9) are remediated within 7 days

10.2 Automated Vulnerability Scanning

Automated vulnerability scans are executed regularly and results are documented. Known vulnerabilities in deployed components are continuously monitored through dependency auditing tools.

10.3 Responsible Disclosure

Vulnerabilities can be responsibly reported to security@conport.services. Reported vulnerabilities are assessed and remediated without delay. Reporters receive an acknowledgement within 5 business days.

§ 11 Physical Security

• EU data centers: All production data is processed and stored exclusively in data centers within the European Union
• ISO 27001 certification: The data centers used are certified to ISO 27001 or an equivalent standard
• Physical access control: Data center access is restricted to authorized personnel (biometric controls, video surveillance, 24/7 security staff)
• CONPORT premises: Office spaces are secured against unauthorized access; screen locks are mandatory

§ 12 Incident Management

12.1 Incident Response Plan

Security incidents are handled in accordance with the detailed Incident Response Plan, which defines detection, containment, remediation, and post-incident review processes.

12.2 GDPR Notification Obligations

Personal data breaches are reported to the competent supervisory authority in accordance with Art. 33 GDPR within 72 hours of becoming aware, where a risk to data subjects cannot be ruled out. Customers are informed without undue delay — and no later than within 24 hours — of incidents affecting them (see also DPA § 7).

12.3 Escalation Matrix

An internal escalation matrix defines, for each severity level (P1–P4), which persons are to be notified and which measures must be initiated within which timeframe. The escalation matrix forms part of the Incident Response Plan.

§ 13 Training and Awareness

• Annual mandatory training: All employees complete an annual information security training covering current threats, policies, and technical measures.
• Onboarding briefing: New employees and external contractors receive a security briefing prior to their first system access and confirm in writing that they have read and understood this policy.
• Phishing awareness: Regular phishing simulations and awareness campaigns train employees to recognize and respond to social engineering attacks.
• Documentation: Training records are archived for each employee.

§ 14 Review and Updates

This policy is reviewed regularly and updated as necessary:

• Annual review: At least once per year, typically in the first quarter of the financial year
• After significant incidents: Following security incidents of severity P1 or P2, the policy is immediately assessed and adjusted if required
• After major architecture changes: Upon fundamental changes to the platform architecture or infrastructure
• Following regulatory changes: When new legal requirements make an update necessary

Changes are documented with version control. The current version is always available at this URL.

---

Questions regarding information security should be directed to: security@conport.services