Security Philosophy & Technical Posture (TOMs / Art. 32 GDPR)
At Alkentar, security is an architectural cornerstone, not an afterthought. We build modern distributed systems and enterprise AI pipelines designed to withstand hostile internet environments.
Our infrastructure adheres to the Technical and Organizational Measures (TOMs) required under Article 32 of the GDPR and incorporates the resilience mandates of Directive (EU) 2022/2555 (NIS2 Directive). Key defensive safeguards include:
• Zero Trust Network Architecture (ZTNA) with strict micro-segmentation across staging, development, and production environments.
• Mandatory Multi-Factor Authentication (MFA / WebAuthn FIDO2 keys) on all administrative systems, code repositories, and cloud control planes.
• Universal Encryption: TLS 1.3 with mandatory HTTP Strict Transport Security (HSTS) and ephemeral Diffie-Hellman key exchanges in transit; AES-256-GCM encryption at rest across all disks, vector stores, and object buckets.
• Automated DevSecOps Pipelines: Real-time Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), automated dependency vulnerability alerts, and secret leak detection integrated into every Git commit.
Legal Safe Harbor Policy for Security Researchers
Alkentar believes that responsible, independent security researchers play a critical role in internet safety. We provide a binding Legal Safe Harbor pledge to anyone reporting vulnerabilities in good faith:
• Authorization: If you conduct vulnerability research within the scope and rules outlined in this document, we consider your actions to be authorized under applicable computer fraud and abuse laws (such as § 202a StGB in Germany or corresponding EU national criminal statutes).
• No Legal Action: We will not initiate civil litigation or contact law enforcement regarding your research activities as long as you act in accordance with this policy.
• Collaboration: We will work collaboratively with you to validate, understand, and remediate reported security vulnerabilities.
We pledge never to pursue legal remedies against ethical researchers who discover issues inadvertently or systematically in good faith and follow our coordinated disclosure timeline.
Research Scope Matrix (In-Scope & Out-of-Scope)
To ensure clarity, vulnerability assessments must be confined strictly to the targets listed below:
| Target Category | Asset Identifier | Status |
|---|---|---|
| Primary Web Properties | alkentar.com and www.alkentar.com | IN-SCOPE |
| Public API Gateways | api.alkentar.com and edge routing gateways | IN-SCOPE |
| Core Subdomains | *.alkentar.com (excluding third-party SaaS widgets) | IN-SCOPE |
| Volumetric Traffic / DDoS | Any attempt to degrade server availability or bandwidth exhaustion | STRICTLY OUT-OF-SCOPE |
| Social Engineering | Phishing, spear-phishing, or pretexting of Alkentar employees or contractors | STRICTLY OUT-OF-SCOPE |
| Physical Security | Physical attacks against data centers, offices, or facilities | STRICTLY OUT-OF-SCOPE |
| Client Infrastructure | Any production tenant, private database, or repository of an Alkentar client | STRICTLY OUT-OF-SCOPE |
Guidelines for Responsible Research
Researchers must adhere to the following operational standards during their investigations:
1. Do No Harm: Avoid data deletion, service degradation, rate-limit bypassing, or unauthorized access to other users’ or clients’ accounts.
2. Immediate Stop on Sensitive Data Discovery: If you inadvertently gain access to personally identifiable information (PII), proprietary source code, or financial records, STOP immediately. Do NOT download, view, copy, or distribute this data. Report the issue at once.
3. Coordinated Disclosure (90 Days): Give Alkentar a reasonable coordinated window (standard 90 calendar days from confirmation) to investigate and deploy patches before disclosing any technical details publicly.
4. Proof of Concept (PoC) Limits: Use the minimum actionable proof-of-concept necessary (e.g., executing a harmless `alert(1)` or reading system version headers instead of modifying database records).
Vulnerability Submission Protocol & PGP Encryption
To ensure confidential transmission, please submit all vulnerability reports to our dedicated security inbox using PGP encryption whenever sensitive payloads or proof-of-concept code are attached:
• Security Inquiries Email: security@alkentar.com
• PGP Key ID: 0x7A4C8E29B190F623
• PGP Fingerprint: 9F82 41A7 62D0 8E11 B4F9 3C90 7A4C 8E29 B190 F623
Your report should include: (a) Clear vulnerability title and affected component; (b) Step-by-step reproduction instructions; (c) Proof of concept code or HTTP request payloads; (d) Estimated CVSS v3.1 severity rating; and (e) Suggested remediation if known.
Email: security@alkentar.com • PGP Key available via public keyservers (keys.openpgp.org) • Encrypted communications ensure zero third-party eavesdropping.
Response Service Level Agreement (SLA)
We respect the time and effort invested by security professionals. Our security operations team commits to the following timelines:
| Phase | Target Timeline | Action Taken |
|---|---|---|
| Initial Acknowledgment | < 24 Business Hours | Automated ticket creation and human confirmation of email receipt |
| Triage & Severity Rating | < 72 Business Hours | Validation of PoC by senior security engineers and CVSS assignment |
| Status Updates | Every 5 Business Days | Progress reports on patch development, staging testing, and rollout |
| Remediation & Verification | < 30 to 90 Days | Deployment of patch to production, followed by researcher verification |
| Public Coordination | Upon mutual agreement | Attribution in Hall of Fame and coordinated disclosure release |
Technical & Organizational Security Measures (TOMs Table)
Below is a summary of technical security controls implemented across the Alkentar engineering lifecycle:
| Security Domain | Implemented Control | Standards Alignment |
|---|---|---|
| Access Control | Zero Trust IAM, Role-Based Access Control (RBAC), FIDO2 WebAuthn MFA, Just-in-Time access elevation | ISO 27001 A.9 / GDPR Art. 32(1)(b) |
| Data Transmission | Mandatory TLS 1.3, Strict Transport Security (HSTS), DNSSEC, automated certificate lifecycle rotation | NIS2 Art. 21 / GDPR Art. 32(1)(a) |
| Data Storage | AES-256-GCM hardware encryption at rest, customer-managed KMS keyrings, ephemeral staging databases | GDPR Art. 32(1)(a) |
| Vulnerability Mgmt | Continuous SAST, DAST, secret scanning, software bill of materials (SBOM), 24/7 endpoint telemetry | ISO 27001 A.12.6 |
| Incident Readiness | Documented 72-hour GDPR Art. 33 breach notification workflow, hot failover backups, annual simulation drills | NIS2 Art. 23 / GDPR Art. 33 |
Security Incident Notification Protocol (GDPR Art. 33 & NIS2)
Alkentar maintains a formal Computer Security Incident Response Plan (CSIRP). In the event of a confirmed security incident impacting customer data or critical system components:
• 72-Hour Regulatory Notice: Notification to competent European supervisory authorities within 72 hours of becoming aware of a personal data breach, pursuant to Article 33 of the GDPR.
• Customer Notification: Immediate written notification to impacted enterprise clients without undue delay pursuant to Article 34 of the GDPR, providing an assessment of the nature of the breach, affected records, and remediation measures taken.
• Forensic Post-Mortem: Comprehensive root-cause analysis and architectural hardening to prevent recurrence.
Recognition & Security Hall of Fame
We are proud to acknowledge security researchers who have helped safeguard Alkentar and our clients through responsible disclosures.
Upon successful resolution of an eligible in-scope vulnerability, researchers will be invited to be listed on Alkentar’s public Security Hall of Fame (including researcher name, social handle, and CVE link if applicable), subject to the researcher’s preference.
Questions Regarding Legal Terms?
Our European legal, compliance, and data protection officers are at your disposal.