Security Policy

Version: 3.1.0 | Effective Date: 2026-03-11

1. Our Security Commitment

MyProtektor is operated by Mike Roth, Founder, Michael-Gaismayr-Strasse 52b, 6900 Bregenz, Austria, European Union, and provides cloud-based security guard management software to professional security firms across Southern Africa. We recognise that our customers depend on the confidentiality, integrity, and availability of our platform to carry out safety-critical operations every day.

This Security Policy describes the administrative, technical, and physical safeguards we implement to protect the data processed through our Service. It applies to all components of the MyProtektor platform, including the web dashboard, mobile applications, application programming interfaces, backend infrastructure, and internal operational systems.

2. Data Protection

2.1 Encryption at Rest

All data stored within the MyProtektor platform is encrypted at rest using AES-256 encryption, the same standard used by financial institutions and government agencies worldwide. This applies to all platform databases, object storage buckets, and backup archives. Encryption keys are managed by enterprise cloud key management systems and are rotated automatically on a regular schedule.

2.2 Encryption in Transit

Every data transmission between your device and our servers is protected by Transport Layer Security (TLS) version 1.2 or higher. This includes all API requests from the mobile application, all web dashboard interactions, webhook deliveries, and inter-service communications within our backend infrastructure. We enforce HTTPS across all endpoints and do not support unencrypted HTTP connections.

2.3 Cryptographic QR Code Signing

Our QR Patrol Verification system uses Ed25519 digital signatures to ensure the authenticity and integrity of patrol checkpoint codes. QR codes are signed server-side using a private key that never leaves our secure backend environment. Guard mobile devices verify signatures using the corresponding public key, which means scanned QR data can be validated as genuine without exposing any secret material on the device.

• Algorithm: Ed25519 (Curve25519-based Edwards-curve Digital Signature Algorithm)
• Key Length: 256-bit private key, 256-bit public key
• QR Expiry: Each signed QR code includes a 24-hour validity window
• Replay Protection: Unique token identifiers prevent code reuse

2.4 Key Management

Cryptographic keys used by the platform are stored in secure environment variables on our hosting provider and are never committed to source code repositories. Production keys are distinct from development and staging keys. Key rotation procedures are documented and executed periodically, with backward-compatible verification support during transition periods.

3. Access Control

3.1 Multi-Factor Authentication

MyProtektor supports multi-factor authentication (MFA) for all user accounts. Account owners and administrators are strongly encouraged to enable MFA. When enabled, users must provide a second verification factor, such as a time-based one-time password (TOTP) generated by an authenticator application, in addition to their password when signing in.

3.2 Role-Based Access Control

The platform enforces a hierarchical role-based access control (RBAC) system with four primary roles, each granting progressively broader permissions:

• Private Client (LiteClient): Read-only access to published incident reports and guard activity summaries for their assigned properties.
• Guard: Ability to create incident reports, scan patrol QR codes, trigger panic alerts, and update their own status and location.
• Admin: Full operational management including guard assignment, incident escalation, QR code generation, site management, and team oversight.
• Owner: All Admin capabilities plus billing management, subscription control, organisation settings, and the ability to invite or remove any user.

Permissions are enforced at every layer of the application: the user interface restricts visible actions, the API validates role requirements on every request, and server-side security rules provide a final server-side enforcement barrier.

3.3 Principle of Least Privilege

Every user, service account, and system component is granted only the minimum level of access necessary to perform its intended function. Administrative access to production infrastructure is limited to the platform founder and is protected by hardware security keys and IP-based access restrictions.

3.4 Session Management

User sessions are managed through a secure authentication service with HTTP-only session tokens. Sessions expire after a configurable period of inactivity. Concurrent session limits may be enforced for sensitive roles. Users can view and revoke active sessions from their account settings.

4. Infrastructure Security

4.1 Cloud Platform

MyProtektor is hosted on enterprise-grade cloud infrastructure, benefiting from modern physical security, network architecture, and operational controls. Our infrastructure providers maintain certifications including ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, and PCI DSS, among others.

4.2 Network Security

Our infrastructure employs multiple layers of network protection including firewalls, intrusion detection systems, and traffic filtering. All incoming traffic is routed through cloud edge load balancing infrastructure, which provides automatic DDoS absorption. We deploy Web Application Firewall (WAF) rules to block common attack patterns including SQL injection, cross-site scripting, and request smuggling.

4.3 DDoS Protection

Built-in cloud DDoS mitigation automatically absorbs and filters volumetric attacks at the network edge before they reach our application servers. This protection operates continuously without manual intervention and can handle multi-terabit attack volumes.

5. Monitoring and Incident Response

5.1 Security Logging

We maintain comprehensive security logs that capture authentication events, API access patterns, administrative actions, data modification operations, and system health metrics. Logs are stored in tamper-resistant storage with a minimum retention period of 90 days and are available for forensic analysis if required.

5.2 Real-Time Alerting

Automated monitoring systems continuously analyse platform behaviour for signs of anomalous activity. Alert triggers include unusual authentication patterns, elevated error rates, unexpected data access volumes, and infrastructure health degradation. Critical alerts are escalated immediately to the responsible operations personnel.

5.3 Incident Response Plan

We maintain a documented incident response plan that defines clear procedures for identifying, containing, eradicating, and recovering from security incidents. The plan includes:

• Detection and Triage: Automated systems and manual review processes to identify and classify security events by severity.
• Containment: Immediate actions to limit the scope and impact of a confirmed security incident, including account isolation and network segmentation.
• Investigation: Thorough root cause analysis using log data, system snapshots, and forensic tools to understand the full extent of the incident.
• Recovery: Restoration of affected systems and data from verified clean backups, followed by enhanced monitoring of restored components.
• Post-Incident Review: A documented review of each significant incident, including lessons learned and corrective actions to prevent recurrence.

5.4 Breach Notification

In the event of a confirmed data breach that affects your personal information, we will notify affected users and the relevant regulatory authorities within 72 hours of becoming aware of the breach, in accordance with the Protection of Personal Information Act (POPIA) and other applicable data protection laws. Breach notifications will include a description of the incident, the categories of data affected, the likely consequences, and the measures taken or proposed to address the breach.

6. Data Centre Security

Our infrastructure runs on certified data centres that implement rigorous physical security controls including 24/7 on-site security personnel, biometric access controls, security cameras with continuous recording, man-trap entry vestibules, and perimeter fencing. Data centre locations are selected to provide low-latency access for our primary user base in Southern Africa while maintaining compliance with applicable data residency preferences.

These data centres operate with redundant power supplies, cooling systems, and network connectivity to ensure high availability. Regular third-party audits verify compliance with physical security standards.

7. Development Security Practices

7.1 Secure Code Development

All code changes to the MyProtektor platform undergo mandatory peer review before deployment. Our development process includes static code analysis, linting for security anti-patterns, and automated testing at unit, integration, and end-to-end levels. Production deployments follow a staged rollout process with automated rollback capabilities.

7.2 Dependency Management

Third-party dependencies are regularly scanned for known vulnerabilities using automated tools. Critical and high-severity vulnerabilities in dependencies are prioritised for immediate remediation. We maintain a software bill of materials (SBOM) and track the security posture of all libraries and frameworks used in the platform.

7.3 Security Testing

We conduct periodic security assessments of the platform including vulnerability scanning, penetration testing of critical components, and review of security configurations. Identified vulnerabilities are classified by severity and remediated according to defined timelines: critical issues within 24 hours, high issues within 7 days, and medium issues within 30 days.

8. Business Continuity

8.1 Backup Strategy

Platform data is backed up automatically on a continuous basis using managed backup mechanisms. Database backups are stored in geographically separate locations from the primary data to protect against regional failures. Backup integrity is verified through regular automated restoration tests.

8.2 Disaster Recovery

We maintain a disaster recovery plan designed to restore platform operations in the event of a major infrastructure failure. The plan is tested periodically to ensure readiness.

• Recovery Time Objective (RTO): We target a maximum of 4 hours to restore core platform functionality following a major incident.
• Recovery Point Objective (RPO): We target a maximum data loss window of 1 hour, meaning that in the worst case, up to 1 hour of the most recent data may need to be re-entered after recovery.

9. Employee and Contractor Security

9.1 Personnel Vetting

All individuals with access to production systems or customer data undergo appropriate background verification before access is granted. Contractors and third-party service providers with system access are subject to equivalent vetting and are bound by confidentiality agreements.

9.2 Security Training

Personnel with access to the platform's infrastructure or customer data receive security awareness training that covers topics including social engineering recognition, secure coding practices, data handling procedures, and incident reporting. Training is refreshed annually or when significant changes to the threat landscape occur.

9.3 Access Reviews

Access permissions for all personnel are reviewed on a quarterly basis to ensure they remain appropriate. When an individual's role changes or their engagement ends, access is revoked promptly and all credentials are rotated as necessary.

10. Third-Party Security

10.1 Vendor Assessment

We evaluate the security posture of all third-party service providers before integrating their services into our platform. This includes infrastructure, payment processing, mobile messaging, and web delivery providers. Each vendor is assessed against criteria including their security certifications, data processing practices, incident history, and contractual commitments.

10.2 Data Processing Agreements

Where third-party providers process personal data on our behalf, we ensure that appropriate data processing agreements are in place. These agreements define the scope of processing, the security measures required, data retention limits, breach notification obligations, and the rights of data subjects.

11. Compliance Framework

11.1 POPIA Compliance

As a platform operating in South Africa, we are committed to full compliance with the Protection of Personal Information Act, 2013 (POPIA). Our data processing activities are aligned with POPIA's eight conditions for lawful processing, and we have appointed an Information Officer to oversee compliance. See our dedicated POPIA Compliance Statement for detailed information.

11.2 GDPR Awareness

While our primary operations are in Southern Africa, we implement data protection practices that are consistent with the principles of the European Union's General Data Protection Regulation (GDPR). This includes data minimisation, purpose limitation, transparent processing, and respect for data subject rights including access, rectification, and erasure.

11.3 ISO 27001 Alignment

Our information security management practices are modelled on the ISO 27001 framework. While we do not currently hold ISO 27001 certification, we follow its principles in areas including risk assessment, security control implementation, continuous improvement, and management review.

12. Customer Responsibilities

12.1 Account Security

You are responsible for maintaining the security of your MyProtektor account credentials. This includes choosing a strong, unique password, enabling multi-factor authentication, and not sharing your login credentials with others. You must notify us immediately if you suspect that your account has been accessed without authorisation.

12.2 Device Security

Guards and other users accessing MyProtektor through mobile devices are responsible for keeping their devices updated with the latest operating system security patches, using device lock screens, and not installing the application on rooted or jailbroken devices. Compromised devices may expose sensitive operational data.

12.3 Reporting Obligations

If you become aware of any security vulnerability, suspicious activity, or potential data breach involving the MyProtektor platform, we ask that you report it to us promptly. Early reporting allows us to investigate and respond quickly, minimising potential harm.

13. Security Incident Reporting

We encourage responsible disclosure of security vulnerabilities. If you discover a potential security issue in the MyProtektor platform, please report it to us using the contact details below. We ask that you:

• Provide sufficient detail for us to understand and reproduce the issue.
• Allow reasonable time for us to investigate and address the vulnerability before making any public disclosure.
• Do not access, modify, or delete data belonging to other users during your research.
• Do not perform any testing that could degrade, disrupt, or damage the platform or its users' experience.

We will acknowledge receipt of your report within 48 hours and keep you informed of our progress in addressing the issue.

14. Contact Us

If you have questions about this Security Policy, wish to report a security concern, or need further information about our security practices, please contact us: