Data Processing Agreement

Last Updated: November 1, 2025

ANNEX 2: SECURITY MEASURES

Data Processing Agreement - Annex 2 S.C. ORGO INFORMATICS SRL Last Updated: November 1, 2025

This Annex 2 is incorporated into and forms part of the Data Processing Agreement between Orgo and Customer.

1. INTRODUCTION AND SECURITY FRAMEWORK

1.1 Purpose

This Annex describes the technical and organizational measures implemented by Orgo to protect Personal Data processed on behalf of Customer in accordance with:

GDPR Article 32 (Security of Processing)
ISO/IEC 27001:2013/2022 (Information Security Management)
NIST Cybersecurity Framework
SOC 2 Type II principles (Security, Availability, Confidentiality)
CCPA security requirements for service providers
Industry best practices for SaaS platforms

1.2 Security Principles

Orgo's security program is based on the following principles:

(a) Confidentiality

Ensuring Personal Data is accessible only to authorized individuals
Preventing unauthorized disclosure or access

(b) Integrity

Ensuring Personal Data is accurate, complete, and not altered without authorization
Detecting and preventing unauthorized modifications

(c) Availability

Ensuring authorized users can access Personal Data when needed
Maintaining system uptime and resilience

(d) Resilience

Ensuring systems can withstand and recover from incidents
Implementing redundancy and failover mechanisms

(e) Defense in Depth

Implementing multiple layers of security controls
Ensuring that failure of one control does not compromise overall security

(f) Least Privilege

Granting users the minimum access necessary to perform their duties
Regularly reviewing and revoking unnecessary access

(g) Security by Design

Integrating security into all stages of system development and operation
Proactively identifying and mitigating risks

1.3 Risk Assessment

Orgo conducts regular risk assessments to:

Identify threats and vulnerabilities to Personal Data
Evaluate the likelihood and impact of security incidents
Determine appropriate security measures based on risk level
Update security controls as threats evolve

Risk assessments consider:

State of the art in security technology
Costs of implementation
Nature, scope, context, and purposes of Processing
Risks to Data Subject rights and freedoms

1.4 Scope

These security measures apply to:

All Personal Data processed by Orgo on behalf of Customer
All Orgo systems, networks, and facilities involved in Processing
All Orgo personnel with access to Personal Data
All Subprocessors engaged by Orgo

2. GOVERNANCE AND POLICIES

2.1 Information Security Management System (ISMS)

Orgo has established an Information Security Management System (ISMS) aligned with ISO 27001, including:

(a) Security Policy

Documented information security policy approved by management
Defines Orgo's commitment to protecting Personal Data
Reviewed and updated annually

(b) Roles and Responsibilities

Data Protection Officer: Vasile Varzariu-Darie (privacy@orgo.space)
Security Officer: Responsible for implementing and monitoring security measures
Incident Response Team: Designated personnel for handling security incidents
System Administrators: Responsible for maintaining secure infrastructure

(c) Risk Management

Annual risk assessments
Risk treatment plans
Risk register maintained and reviewed quarterly

(d) Security Objectives

Defined security objectives aligned with business goals
Measurable key performance indicators (KPIs) and key risk indicators (KRIs)

2.2 Security Documentation

Orgo maintains the following security documentation:

Security Policies: Access control, encryption, incident response, acceptable use, data classification
Security Procedures: Detailed instructions for implementing security controls
Security Standards: Technical requirements for systems and applications
Security Guidelines: Best practices for personnel
Records: Audit logs, incident reports, risk assessments, training records

2.3 Change Management

All changes to production systems are subject to a formal change management process:

Change requests must be documented and approved
Security impact assessment required for all changes
Testing in non-production environment before deployment
Rollback procedures in place
Change log maintained

2.4 Configuration Management

Orgo maintains secure baseline configurations for all systems:

Hardened operating systems and applications
Unnecessary services and software disabled or removed
Default passwords changed
Security patches applied regularly
Configuration changes tracked and audited

2.5 Policy Review and Updates

All security policies, procedures, and standards are reviewed:

Annually (at minimum)
Upon significant changes to systems, threats, or regulations
Following security incidents or audit findings
When recommended by industry best practices

3. ACCESS CONTROLS

3.1 User Authentication

(a) Strong Password Requirements

Minimum 12 characters (for Orgo personnel); minimum 8 characters (for Customer users, configurable)
Combination of uppercase, lowercase, numbers, and special characters
Password complexity enforced by system
Password history (cannot reuse last 5 passwords)
Maximum password age: 90 days (for Orgo personnel)

(b) Multi-Factor Authentication (MFA)

Mandatory for all Orgo personnel accessing production systems
Available and recommended for Customer Administrators (can be made mandatory by Customer)
Supports authenticator apps (TOTP), SMS, and hardware tokens
Backup codes provided for account recovery

(c) Single Sign-On (SSO)

Customer may enable SSO via Google, Microsoft, Apple, LinkedIn
OAuth 2.0 and OpenID Connect protocols
SSO tokens encrypted and time-limited

(d) Session Management

Encrypted session cookies (HTTPS-only, Secure, SameSite flags)
Automatic session timeout after 30 minutes of inactivity (configurable by Customer)
Session invalidation upon logout
Concurrent session limits

3.2 Role-Based Access Control (RBAC)

(a) Principle of Least Privilege

Users granted only the minimum access necessary for their role
Separation of duties implemented where appropriate
Access rights reviewed quarterly

(b) User Roles

Orgo Personnel: Limited roles based on job function (developer, support, administrator)
Customer Administrators: Full access to Customer's organization data
End Users: Access limited to their own data and organization content based on Customer's settings

(c) Access Approval Process

All access requests must be documented and approved by authorized personnel
Identity verification required for new accounts
Access provisioning follows documented procedures
Access revocation upon role change or termination (within 24 hours)

3.3 Privileged Access Management

(a) Administrative Access

Privileged access to production systems limited to authorized personnel
Separate privileged accounts for administrative tasks (no shared accounts)
Just-in-time (JIT) access provisioning where possible
All privileged actions logged and monitored

(b) Root and Superuser Access

Root and superuser access restricted to designated administrators
Root login disabled on all production servers
Sudo access used instead, with logging

(c) Service Accounts

Service accounts used only for automated processes
Strong, randomly generated passwords
Regular rotation of service account credentials
Service accounts do not have interactive login capability

3.4 Access Reviews and Revocation

(a) Regular Access Reviews

Quarterly review of all user access rights
Annual certification by managers of their team members' access
Removal of unnecessary or outdated access

(b) Immediate Revocation

Access revoked within 24 hours of employee termination or role change
Termination checklist includes revocation of all access credentials
Remote access (VPN, SSH keys) terminated immediately
Company devices collected and wiped

(c) Dormant Account Deactivation

Accounts inactive for 90 days automatically disabled
Disabled accounts deleted after 180 days (unless required for audit/legal purposes)

3.5 Access Logging and Monitoring

All authentication attempts (successful and failed) logged
All access to Personal Data logged (user, timestamp, action)
Logs stored securely and retained for 12 months
Automated alerts for suspicious access patterns:
Multiple failed login attempts (5+ within 15 minutes)
Login from unusual locations or devices
Access to large volumes of data
Privileged account usage outside business hours

4. DATA ENCRYPTION

4.1 Encryption in Transit

(a) TLS/SSL Encryption

TLS 1.2 or higher for all data in transit
TLS 1.3 preferred where supported
Strong cipher suites only (AES-256, Perfect Forward Secrecy)
HSTS (HTTP Strict Transport Security) enabled
All HTTP traffic redirected to HTTPS

(b) API and Web Services

All API endpoints require HTTPS
OAuth tokens encrypted in transit
Webhook payloads encrypted
SSO authentication encrypted (OAuth 2.0, OpenID Connect)

(c) Email Communications

TLS encryption for email transmission (SMTP with STARTTLS)
Sensitive data in emails encrypted or transmitted via secure links

(d) Mobile App Communications

Certificate pinning for mobile apps
End-to-end encryption for sensitive operations

4.2 Encryption at Rest

(a) Database Encryption

AES-256 encryption for all databases containing Personal Data
AWS RDS encryption enabled
Database backups encrypted with AES-256

(b) File Storage Encryption

AWS S3 server-side encryption (SSE-S3 or SSE-KMS) for all uploaded files
Encrypted storage for documents, images, videos
Encryption keys managed by AWS KMS

(c) Disk Encryption

Full disk encryption (FDE) for all servers and workstations
AWS EBS volume encryption enabled
Encrypted snapshots for backups

(d) Application-Level Encryption

Sensitive fields (e.g., passwords, tokens) encrypted before storage
bcrypt or Argon2 hashing for passwords (one-way, salted)
Encrypted storage for API keys and secrets

4.3 Key Management

(a) Encryption Key Storage

Encryption keys stored separately from encrypted data
AWS Key Management Service (KMS) used for key management
Hardware security modules (HSMs) for key generation and storage

(b) Key Rotation

Encryption keys rotated annually (or more frequently based on risk assessment)
Automated key rotation for KMS-managed keys
Old keys retained for decryption of archived data

(c) Key Access Control

Access to encryption keys restricted to authorized personnel
All key access logged and monitored
Multi-person authorization required for key operations (where applicable)

4.4 End-to-End Encryption (E2EE)

(a) Direct Messages (Future Enhancement)

Orgo is evaluating implementation of optional E2EE for direct messages
If implemented, encryption keys would be controlled by End Users, not Orgo

(b) Limitations

E2EE not currently available for most features (posts, events, etc.) as these require server-side processing for search, notifications, analytics

5. NETWORK SECURITY

5.1 Firewalls and Network Segmentation

(a) Firewall Configuration

Stateful firewalls deployed at network perimeter
Default-deny firewall rules (whitelist approach)
Unnecessary ports and protocols blocked
Firewall rules reviewed quarterly

(b) Network Segmentation

Production environment isolated from development and testing
Database servers isolated from application servers
Sensitive systems on separate VLANs or subnets
Customer data logically separated (multi-tenant isolation)

(c) AWS Security Groups

Security groups configured with principle of least privilege
Inbound traffic restricted to necessary ports and IP ranges
Egress traffic monitored and controlled

5.2 Intrusion Detection and Prevention

(a) IDS/IPS Systems

AWS GuardDuty for threat detection across AWS accounts
VPC Flow Logs analysis for network anomalies
Signature-based and anomaly-based detection
Alerts sent to security team for investigation via CloudWatch

(b) DDoS Protection

AWS Shield Standard for infrastructure-level DDoS protection (Layer 3/4)
AWS WAF for application-layer DDoS protection (Layer 7)
Rate limiting and traffic throttling via WAF rules
Automatic mitigation of volumetric attacks
CloudWatch metrics and alarms for attack detection

5.3 Virtual Private Network (VPN)

(a) Remote Access

VPN required for all remote access to production systems
Strong encryption (AES-256, IKEv2/IPsec)
MFA required for VPN authentication
VPN access logs monitored

(b) Site-to-Site VPN

Encrypted connections between Orgo systems and Subprocessors (where applicable)
IPsec or TLS VPN tunnels

5.4 Web Application Firewall (WAF)

AWS WAF protects against common web attacks:
SQL injection
Cross-site scripting (XSS)
Cross-site request forgery (CSRF)
Remote file inclusion (RFI)
Directory traversal
OWASP Top 10 vulnerabilities
AWS Managed Rules for common threat protection
Custom WAF rules for application-specific threats
Rate limiting to prevent abuse and DDoS
Bot detection and mitigation (AWS WAF Bot Control)
Geo-blocking capabilities
IP reputation lists (AWS Managed Threat Intelligence)

5.5 DNS Security

Cloudflare DNS service for high availability and fast resolution
DNSSEC enabled for enhanced security
DDoS-resistant DNS infrastructure
Regular monitoring of DNS records for unauthorized changes
AWS Route53 as backup DNS provider

6. INFRASTRUCTURE SECURITY

6.1 Cloud Hosting (AWS)

(a) Data Residency

Primary hosting: AWS Frankfurt, Germany (eu-central-1)
All Customer Personal Data stored in EU
Backup region: AWS Frankfurt (separate availability zones)

(b) AWS Security

AWS infrastructure complies with:
ISO 27001, ISO 27017, ISO 27018
SOC 2 Type II
PCI DSS Level 1
GDPR, HIPAA (where applicable)
AWS Shared Responsibility Model: AWS secures infrastructure; Orgo secures application and data

(c) AWS Services Used

EC2 / ECS: Compute instances (hardened, patched, monitored)
Aurora RDS MySQL: Managed database service (Multi-AZ, encrypted, automated backups, continuous backup)
S3: Object storage (encrypted, versioning enabled, lifecycle policies)
CloudWatch: Monitoring and alerting (metrics, logs, alarms)
CloudTrail: API audit logging
GuardDuty: Threat detection and monitoring
IAM: Identity and access management
KMS: Key management (Hardware Security Modules)
VPC: Virtual private cloud (network isolation)
WAF: Web Application Firewall (OWASP Top 10 protection, rate limiting)
Shield Standard: DDoS protection

6.2 Server Hardening

(a) Operating System Hardening

Minimal OS installation (unnecessary packages removed)
CIS (Center for Internet Security) benchmarks applied
Security patches applied within 30 days of release (critical patches within 7 days)
Automated patch management

(b) Service Hardening

Unnecessary services disabled
Default accounts and passwords changed or disabled
Services run with least privilege (non-root users)
Security configuration reviewed regularly

(c) Vulnerability Management

Automated vulnerability scanning (weekly)
Vulnerabilities prioritized and remediated based on severity:
Critical: Within 7 days
High: Within 30 days
Medium: Within 90 days
Low: Addressed in next maintenance cycle
Vulnerability management system tracks and reports remediation status

6.3 Container Security (If Applicable)

If Orgo uses containerization (Docker, Kubernetes):

Base images scanned for vulnerabilities
Containers run as non-root users
Resource limits enforced
Secrets not hardcoded in images
Regular updates of base images

6.4 High Availability and Redundancy

(a) Multi-Availability Zone Deployment

Application deployed across multiple AWS availability zones
Automatic failover if one AZ fails
Load balancing across AZs

(b) Auto-Scaling

Automatic scaling of compute resources based on demand
Ensures availability during traffic spikes

(c) Database Replication

Aurora RDS Multi-AZ deployment with automatic failover (1-2 minutes)
Real-time replication to standby replica in different availability zone
Read replicas for improved read performance and scalability
Continuous backup with 5-minute granularity

7. APPLICATION SECURITY

7.1 Secure Development Lifecycle (SDLC)

(a) Security by Design

Security requirements defined at project initiation
Threat modeling conducted for new features
Security architecture review

(b) Secure Coding Practices

Developers trained in secure coding (OWASP guidelines)
Input validation and output encoding
Parameterized queries (prevent SQL injection)
CSRF tokens for state-changing operations
Content Security Policy (CSP) headers
Secure session management

(c) Code Review

Peer code review required for all changes
Security-focused code review for sensitive features
Automated code analysis tools integrated into CI/CD pipeline

7.2 Application Security Testing

(a) Static Application Security Testing (SAST)

Automated static code analysis
Scans for vulnerabilities in source code
Integrated into CI/CD pipeline

(b) Dynamic Application Security Testing (DAST)

Automated security scans of running application
Tests for runtime vulnerabilities (SQL injection, XSS, etc.)
Conducted in staging environment before production deployment

(c) Dependency Scanning

Automated scanning of third-party libraries and dependencies
Alerts for known vulnerabilities (CVEs)
Dependencies updated regularly

(d) Penetration Testing

Annual third-party penetration testing
Scope includes web application, APIs, infrastructure
Findings remediated based on severity
Re-testing conducted to verify fixes

7.3 API Security

(a) Authentication and Authorization

OAuth 2.0 for API authentication
JWT tokens with expiration
Scope-based authorization
Rate limiting per API key

(b) API Security Best Practices

Input validation and sanitization
Output encoding
HTTPS required for all API endpoints
API versioning
Comprehensive API documentation

7.4 Security Headers

Orgo implements security headers to protect against common attacks:

Content-Security-Policy (CSP): Prevents XSS
X-Frame-Options: Prevents clickjacking
X-Content-Type-Options: Prevents MIME sniffing
Strict-Transport-Security (HSTS): Enforces HTTPS
Referrer-Policy: Controls referrer information
Permissions-Policy: Controls browser features

7.5 Protection Against Common Vulnerabilities

(a) SQL Injection

Parameterized queries and prepared statements
ORM (Object-Relational Mapping) framework
Input validation
Least privilege database accounts

(b) Cross-Site Scripting (XSS)

Output encoding (HTML, JavaScript, URL encoding)
Content Security Policy (CSP)
Input sanitization
Templating engines with auto-escaping

(c) Cross-Site Request Forgery (CSRF)

CSRF tokens for all state-changing operations
SameSite cookie attribute
Origin and Referer header validation

(d) Clickjacking

X-Frame-Options: DENY or SAMEORIGIN
Content-Security-Policy: frame-ancestors directive

(e) Session Hijacking

HTTPS-only cookies
HttpOnly and Secure cookie flags
Session regeneration after login
Session invalidation after logout

8. PERSONNEL SECURITY

8.1 Background Checks

(a) Pre-Employment Screening

Background checks conducted for employees with access to Personal Data (to the extent permitted by Romanian law)
Verification of identity and employment history
Professional reference checks

(b) Ongoing Screening

Periodic re-screening for employees with privileged access (every 3 years)

8.2 Confidentiality Obligations

(a) Confidentiality Agreements

All employees and contractors sign confidentiality agreements
Agreements cover protection of Personal Data
Obligations survive termination of employment

(b) Professional Secrecy

Employees bound by statutory obligations of confidentiality under Romanian law

8.3 Security Training

(a) Initial Training

Mandatory security and privacy training for all new employees
Completed within first 30 days of employment
Covers:
Data protection principles and GDPR requirements
Orgo's security policies and procedures
Incident reporting
Social engineering and phishing awareness
Secure coding practices (for developers)

(b) Ongoing Training

Annual refresher training for all employees
Additional training for employees with access to sensitive systems
Training on new threats and vulnerabilities
Phishing simulation exercises (quarterly)

(c) Training Records

Training completion tracked and documented
Training materials kept up-to-date

8.4 Acceptable Use Policy

Employees must comply with Acceptable Use Policy:

Use company resources only for authorized purposes
No unauthorized access to Personal Data
No sharing of credentials
Report security incidents immediately
Secure workstations when unattended (lock screen)
No installation of unauthorized software
No use of personal devices for accessing production systems (unless approved and secured)

8.5 Termination Procedures

Upon employee termination:

Access revoked within 24 hours (see Section 3.4)
Company devices returned and wiped
Confidentiality obligations reminder provided
Exit interview includes security reminders
Knowledge transfer to ensure continuity

9. PHYSICAL SECURITY

9.1 Data Center Security (AWS)

Orgo uses AWS data centers, which implement comprehensive physical security:

(a) Perimeter Security

Professional security staff 24/7
Video surveillance
Intrusion detection systems
Access control barriers

(b) Access Controls

Multi-factor authentication for data center entry
Biometric access controls
Visitor logs and escort requirements
Need-to-know access restrictions

(c) Environmental Controls

Climate control (HVAC systems)
Fire detection and suppression
Power redundancy (UPS, generators)
Seismic and flood protection

(d) AWS Compliance

AWS data centers certified for ISO 27001, SOC 2, and other security standards
Regular third-party audits
Compliance reports available to customers

9.2 Office Security (Orgo Offices)

(a) Access Controls

Locked office premises
Key or card access for authorized personnel
Visitor sign-in and escort requirements
After-hours access restricted

(b) Workstation Security

Automatic screen lock after 5 minutes of inactivity
Clean desk policy (sensitive documents locked away)
Secure disposal of paper documents (shredding)
Full disk encryption on all workstations

(c) Equipment Security

Inventory of all IT equipment
Asset tags and tracking
Secure storage for backup media
Equipment disposal follows secure sanitization procedures

10. MONITORING AND LOGGING

10.1 Security Monitoring

(a) 24/7 Monitoring

Automated security monitoring and alerting
Real-time detection of security events
Security Information and Event Management (SIEM) system

(b) Monitored Events

Authentication attempts (successful and failed)
Privileged account usage
System and application errors
Network traffic anomalies
Database access and queries
File access and modifications
Security configuration changes

(c) Alerting

Automated alerts for critical security events
Alert escalation procedures
On-call security personnel for after-hours incidents

10.2 Log Management

(a) Centralized Logging

All systems send logs to centralized logging infrastructure
AWS CloudWatch and CloudTrail for AWS resources
Application logs aggregated and analyzed

(b) Log Content

User authentication and authorization
Access to Personal Data (who accessed what, when)
System and application events
Security events (intrusions, violations, incidents)
Administrative actions
Network traffic logs

(c) Log Protection

Logs encrypted in transit and at rest
Access to logs restricted to authorized personnel
Logs protected from tampering (write-once storage where applicable)
Regular review of log integrity

(d) Log Retention

Security logs retained for 12 months
Audit logs retained as required by regulations (e.g., accounting records: 10 years)
Logs archived to long-term storage after active retention period

10.3 Audit Trails

Orgo maintains comprehensive audit trails for:

All access to Personal Data
All modifications to Personal Data
All administrative actions
All security configuration changes
All authentication events

Audit trails include:

User identity
Timestamp
Action performed
System or resource accessed
Source IP address
Success or failure status

11. INCIDENT RESPONSE AND BREACH MANAGEMENT

11.1 Incident Response Plan

Orgo has a documented Incident Response Plan that defines:

(a) Incident Response Team

Security Officer (incident commander)
System administrators
Legal counsel
Data Protection Officer
Communications lead

(b) Incident Categories

Critical: Active breach, data exfiltration, ransomware, complete service outage
High: Attempted breach, vulnerability exploitation, significant service degradation
Medium: Suspicious activity, minor security violations, limited service impact
Low: Security policy violations, minor configuration issues

(c) Incident Response Phases

Preparation: Maintain incident response plan, train team, deploy monitoring
Detection and Analysis: Identify and assess incidents
Containment: Isolate affected systems, prevent spread
Eradication: Remove threat, patch vulnerabilities
Recovery: Restore systems, verify integrity
Post-Incident: Conduct lessons learned, update procedures

11.2 Personal Data Breach Response

For Personal Data Breaches affecting Customer data:

(a) Immediate Actions (Within 24 Hours)

Contain the breach (isolate affected systems)
Assess scope (what data, how many Data Subjects)
Notify incident response team
Preserve evidence

(b) Customer Notification (Within 72 Hours)

Notify Customer via email to Customer Contact Email
Provide details as specified in DPA Section 10.2.3:
Nature of the breach
Categories and approximate number of affected Data Subjects
Likely consequences
Measures taken and proposed
Contact point for more information

(c) Investigation and Remediation

Conduct thorough investigation (root cause analysis)
Implement remedial measures
Document all actions taken
Provide regular updates to Customer

(d) Assistance to Customer

Assist Customer with notifications to supervisory authorities and Data Subjects
Provide information for breach notification
Cooperate with Customer's investigation
Provide forensic support if needed

11.3 Incident Documentation

All incidents are documented in an incident log, including:

Incident description
Date and time of detection
Affected systems and data
Actions taken
Personnel involved
Resolution and lessons learned

11.4 Testing and Updates

Incident response plan tested annually through tabletop exercises or simulations
Plan updated based on test results, actual incidents, and industry best practices

12. BUSINESS CONTINUITY AND DISASTER RECOVERY

12.1 Business Continuity Plan

Orgo has a Business Continuity Plan (BCP) to ensure continuation of critical services in the event of disruptions:

(a) Critical Services

Core platform availability (authentication, data access)
Data integrity and protection
Customer support

(b) Recovery Time Objectives (RTO)

Critical services: RTO of 4 hours (database failover: 1-2 minutes via Aurora Multi-AZ)
Non-critical services: RTO of 24 hours

(c) Recovery Point Objectives (RPO)

RPO of <1 second for database (data loss limited to last second)
Achieved through AWS Backup continuous backup with 1-second granularity PITR
RPO of 15 minutes for file storage (S3 versioning and replication)

12.2 Disaster Recovery Plan

(a) Disaster Scenarios

Data center failure
Regional outage
Cyberattack (ransomware, DDoS)
Natural disaster
Pandemic or public health emergency

(b) Disaster Recovery Procedures

Automated failover to secondary availability zone (within AWS Frankfurt region)
Restoration from backups if necessary
Alternative work arrangements for personnel (remote work)
Communication plan for customers and stakeholders

(c) Testing

Disaster recovery procedures tested annually
Backup restoration tested quarterly
Test results documented and plan updated

12.3 High Availability Architecture

Multi-AZ deployment (see Section 6.4)
Load balancing and auto-scaling
Database replication
Redundant network paths
No single point of failure in critical systems

13. DATA BACKUP AND RECOVERY

13.0 AWS Backup - Centralized Backup Management

Orgo uses AWS Backup for enterprise-grade, centralized backup orchestration across all AWS resources.

AWS Backup Benefits: (a) Centralized Management

Single console for all backup policies across RDS, S3, EBS, and other AWS services
Consistent backup strategy and governance across all resources
Unified monitoring and reporting

(b) Compliance and Auditing

Automated backup compliance monitoring
Audit trails for all backup operations (via AWS CloudTrail)
Compliance reports demonstrating backup coverage and success rates
Support for regulatory requirements (GDPR, HIPAA, SOC 2)

(c) Point-in-Time Recovery (PITR)

1-second granularity for Aurora RDS continuous backups
Restore database to any specific second within 30-day retention window
Maximum PITR window: 35 days (AWS Backup limit for Aurora)

(d) Security Features

Encryption: All backups encrypted at rest (AES-256) and in transit (TLS)
Access Control: IAM policies and resource-based policies control backup access
Vault Lock: Immutable backups to protect against ransomware and accidental deletion
MFA Required: Multi-factor authentication for backup deletion

(e) Cross-Region and Cross-Account

Cross-region backup: Automated daily backup copy to eu-west-1 (Ireland) for geographic disaster recovery
Geographic redundancy: Data protected in two EU regions (Frankfurt primary, Ireland backup)
Cross-account backup capability for additional data protection (configurable)
Compliance with data residency requirements (EU data stays in EU)

(f) Lifecycle Management

Automated transition to cold storage (if needed for cost optimization)
Automated deletion after retention period expires
Policy-based lifecycle rules

13.1 Backup Schedule

(a) Production Databases (Aurora RDS MySQL via AWS Backup)

Backup Management: AWS Backup service for centralized, enterprise-grade backup orchestration
Continuous backups (PITR): Enabled with 1-second granularity for point-in-time recovery
Daily snapshots: Automated at 22:30 UTC (00:30 Europe/Bucharest time)
Retention: 30 days for both continuous backups and snapshots
Cross-region backup: Automated daily copy to eu-west-1 (Ireland) for disaster recovery
Multi-AZ replication: Real-time synchronous replication across availability zones in Frankfurt region

(b) File Storage (S3)

Versioning enabled (previous versions retained for 30 days)
Cross-region replication to backup region (optional, for Enterprise customers)

(c) Configuration and Code

Configuration files backed up daily
Source code in version control (Git) with off-site repository

13.2 Backup Storage and Protection

(a) Storage Location

Primary backup location: AWS Frankfurt (eu-central-1) - separate from production systems
Cross-region backup location: AWS Ireland (eu-west-1) - automated daily copy for disaster recovery
Geographic redundancy: Within Frankfurt region (multiple availability zones) + cross-region to Ireland
Data residency: All backup data remains within EU borders (Frankfurt and Ireland)

(b) Backup Encryption

All backups encrypted at rest (AES-256)
Encryption keys managed by AWS KMS

(c) Backup Access Control

Access to backups restricted to authorized personnel
MFA required for backup access
All backup access logged

13.3 Backup Retention

Continuous backups (AWS Backup PITR): 30-day retention with point-in-time recovery to any second (1-second granularity)
Daily snapshots (AWS Backup): Retained for 30 days in Frankfurt
Cross-region backups: Automated daily copy to Ireland (eu-west-1) with 30-day retention
Long-term archival: For compliance or legal hold as required (AWS Backup Vault Lock for immutability)

13.4 Backup Testing and Restoration

(a) Restoration Testing

Backup restoration tested quarterly via AWS Backup restore capabilities
Test verifies data integrity and completeness
Test measures restoration time (RTO validation)
AWS Backup compliance reports validate backup success rates and coverage

(b) Restoration Procedures

Point-in-Time Recovery (PITR): Restore database to any second within 30 days
Estimated recovery time: 30-60 minutes
Recovery point objective (RPO): <1 second
Multi-AZ Failover: Automatic failover in case of primary database failure
Estimated recovery time: 1-2 minutes (automatic)
RPO: 0 seconds (synchronous replication, no data loss)
Cross-region restore: Recovery from Ireland backup in case of regional AWS outage
Estimated recovery time: 2-4 hours for full platform recovery
RPO: <1 second for database, 15 minutes for S3 files
File recovery: S3 versioning allows restoration of any file version within 30 days (minutes)
Documented procedures for all restoration scenarios
Restoration can be performed by authorized personnel

(c) Data Recovery Requests

Customer may request data restoration (e.g., accidental deletion)
Restoration performed within 24-48 hours (depending on scope)
May be subject to fees for large or complex restoration requests

14. DATA DISPOSAL AND DESTRUCTION

14.1 Secure Deletion

(a) Data Deletion Methods

Standard deletion: Data marked as deleted in database (overwritten by subsequent backups within 90 days)
Secure deletion: Data securely overwritten or cryptographically erased
Cryptographic erasure: Encryption keys destroyed, rendering data unrecoverable

(b) Deletion Timeframes

Production systems: Within 30 days of deletion request
Backups: Within 90 days (as backups are overwritten on a rolling basis)
Logs: Within 12 months (standard log retention period)

14.2 Media Disposal

(a) Hard Drives and Storage Media

Physical destruction (shredding, degaussing, or incineration)
Cryptographic erasure if reusing media
AWS-managed destruction for cloud infrastructure (AWS follows NIST 800-88 guidelines)

(b) Paper Documents

Cross-cut shredding for sensitive paper documents
Secure disposal service for large volumes

(c) Electronic Devices

Full disk wipe (multiple overwrite passes) before disposal or reuse
Physical destruction for devices that cannot be wiped
Certificate of destruction obtained where applicable

14.3 Data Retention After Termination

See DPA Section 13 and Annex 1 for data retention periods after Agreement termination.

15. VENDOR AND SUBPROCESSOR SECURITY

15.1 Vendor Due Diligence

Before engaging a Subprocessor, Orgo conducts due diligence:

(a) Security Assessment

Review of vendor's security policies and practices
Review of security certifications (ISO 27001, SOC 2, etc.)
Review of data processing agreement and privacy policy

(b) Risk Assessment

Assessment of risks posed by vendor
Evaluation of vendor's data protection and security measures
Review of vendor's financial stability and reputation

(c) Contractual Protections

Data processing agreement with GDPR-compliant terms
Security obligations equivalent to Orgo's obligations
Audit rights
Breach notification requirements
Data return and deletion obligations

15.2 Ongoing Vendor Management

(a) Annual Reviews

Annual review of vendor security posture
Review of updated certifications and audit reports
Re-assessment of risks

(b) Vendor Audits

Review of vendor SOC 2 or ISO 27001 reports (where available)
On-site audits for critical vendors (if feasible)
Security questionnaires

(c) Incident Management

Vendors required to notify Orgo of security incidents within 24 hours
Orgo coordinates response with vendor
Orgo notifies Customer as required by DPA

15.3 Subprocessor Security Requirements

All Subprocessors must:

Implement security measures equivalent to this Annex 2
Encrypt data in transit and at rest
Restrict access to Personal Data (least privilege)
Provide logs and audit trails
Notify Orgo of security incidents promptly
Comply with GDPR, CCPA, and applicable data protection laws

See Annex 3 (Subprocessors) for list of current Subprocessors and their security measures.

16. SECURITY TESTING AND AUDITS

16.1 Vulnerability Scanning

(a) Automated Scanning

Weekly automated vulnerability scans of all systems
Scans cover operating systems, applications, network devices
Vulnerabilities prioritized and remediated based on severity (see Section 6.2)

(b) Authenticated Scanning

Periodic authenticated scans (with credentials) for deeper analysis
Covers configuration vulnerabilities and missing patches

16.2 Penetration Testing

(a) Annual Penetration Testing

At least annually by independent third-party security firm
Scope: Web application, APIs, infrastructure, social engineering
Types: Black-box (no prior knowledge), gray-box (limited knowledge), white-box (full knowledge)

(b) Findings and Remediation

Penetration test report provided to management
Findings prioritized based on severity
Remediation plan developed
Critical and high findings remediated within 30 days
Re-testing conducted to verify fixes

16.3 Security Audits

(a) Internal Audits

Quarterly internal security audits
Review of security controls, policies, and procedures
Audit findings documented and remediated

(b) External Audits

SOC 2 Type II audit (annually, as resources permit)
ISO 27001 certification audit (planned)
Customer audits as provided in DPA Section 12

(c) Compliance Audits

GDPR compliance reviews
CCPA compliance reviews
Industry-specific compliance (if applicable)

16.4 Security Metrics and Reporting

Orgo tracks and reports security metrics:

Number of vulnerabilities detected and remediated
Mean time to remediate vulnerabilities
Number of security incidents
Patch compliance rate
Security training completion rate
Phishing simulation results

17. SECURITY TRAINING AND AWARENESS

17.1 Security Awareness Program

Orgo maintains an ongoing security awareness program:

(a) Training Topics

Data protection and privacy (GDPR, CCPA)
Phishing and social engineering
Password security and MFA
Secure coding (for developers)
Incident reporting
Physical security
Acceptable use of company resources

(b) Training Methods

Online training modules
In-person or virtual workshops
Lunch-and-learn sessions
Security newsletters and tips
Posters and reminders

(c) Phishing Simulations

Quarterly simulated phishing campaigns
Tracks click rates and reporting rates
Targeted training for employees who fall for simulations

17.2 Specialized Training

(a) Developers

Secure coding training (OWASP Top 10, etc.)
Security code review training
Threat modeling training

(b) Administrators

System hardening and configuration
Incident response procedures
Privileged access management

(c) Customer Support

Data privacy and confidentiality
Social engineering awareness
Handling of Data Subject requests

17.3 Training Records

Training completion tracked in HR system
Certificates of completion issued
Annual refresher training required
Training records retained for 5 years

18. COMPLIANCE AND CERTIFICATIONS

18.1 Regulatory Compliance

Orgo's security measures are designed to comply with:

(a) European Union

GDPR (Regulation 2016/679)
ePrivacy Directive (2002/58/EC)
NIS Directive (Network and Information Security)
Data Act (Regulation 2023/2854)

(b) United Kingdom

UK GDPR
Data Protection Act 2018

(c) Romania

Law 190/2018 (GDPR implementation)
ANSPDCP guidelines

(d) United States

CCPA/CPRA (California)
VCDPA (Virginia)
CPA (Colorado)
Other state privacy laws (Utah, Connecticut, etc.)
COPPA (Children's Online Privacy Protection Act)

(e) Canada

PIPEDA (Personal Information Protection and Electronic Documents Act)

18.2 Security Certifications (Current and Planned)

(a) Current

AWS infrastructure certifications (ISO 27001, SOC 2, PCI DSS) - inherited from AWS
Cloudflare DNS certifications (ISO 27001, SOC 2) - inherited from Cloudflare

(b) Planned

SOC 2 Type II - Planned for 2026
ISO 27001 - Planned for 2026-2027
Privacy Shield successor - When available for EU-US transfers

18.3 Documentation Available to Customers

Upon request, Orgo can provide:

Security policies and procedures (redacted for confidentiality)
AWS infrastructure certifications
Subprocessor certifications
Penetration test summary reports (redacted for security)
Responses to security questionnaires (e.g., CAIQ, SIG)

19. CONTINUOUS IMPROVEMENT

19.1 Security Program Reviews

Orgo reviews and updates its security program:

Quarterly: Review of security metrics, incidents, and emerging threats
Annually: Comprehensive review of all policies, procedures, and controls
Ad-hoc: Following significant incidents or changes in threat landscape

19.2 Industry Best Practices

Orgo monitors and adopts industry best practices:

OWASP (Open Web Application Security Project)
NIST (National Institute of Standards and Technology)
SANS (SysAdmin, Audit, Network, and Security)
CIS (Center for Internet Security)
ISO/IEC 27001/27002
Cloud Security Alliance (CSA)

19.3 Threat Intelligence

Orgo subscribes to threat intelligence feeds to stay informed of:

New vulnerabilities (CVEs)
Emerging threats and attack vectors
Security advisories from vendors
Data breach reports and lessons learned

20. CONTACT INFORMATION

For questions about Orgo's security measures or to report a security concern:

Security Team:

Email: security@orgo.space
For non-urgent inquiries: privacy@orgo.space

Data Protection Officer:

Name: Vasile Varzariu-Darie
Email: privacy@orgo.space
Address: S.C. ORGO INFORMATICS SRL, Str. Gheorghe Grigore Cantacuzino nr 14, etaj PARTER, ap 1, Ploiești, județul Prahova, Romania

Security Incident Reporting:

Email: security@orgo.space (monitored 24/7)
Subject: URGENT - Security Incident
Include: Description, affected systems, your contact information

Vulnerability Disclosure:

Orgo welcomes responsible disclosure of security vulnerabilities
Email: security@orgo.space
Include: Detailed description, proof-of-concept (if safe), impact assessment
We commit to acknowledging within 48 hours and providing updates on remediation

END OF ANNEX 2

This Annex 2 describes the technical and organizational security measures implemented by Orgo as of November 1, 2025. Orgo may update these measures from time to time to reflect advancements in technology, changes in threats, or regulatory requirements, provided such updates do not materially decrease the overall level of security. For the complete Data Processing Agreement, please refer to the main DPA document.