Information Security & Data Management Policy

Last updated: April 1, 2025

1. About This Document

This policy outlines the information security controls and data management practices implemented by Lloyd IT Limited (trading as Valora) for client systems and data. Our security approach is designed to align with ISO 27001 requirements and support our clients' compliance obligations.

As a small development agency, we leverage enterprise-grade infrastructure and managed services to deliver secure, scalable solutions tailored to each client's requirements.

2. Company Information

Lloyd IT Limited (trading as Valora)

Address:
13 Cae'r Delyn
Blackwood
NP12 0NW
United Kingdom

Company Registration: 16349880
Website: https://valoradev.com
Support Email: support@valoradev.com
Security Contact: support@valoradev.com

3. Our Approach

3.1 Infrastructure Philosophy

We offer flexible hosting solutions based on client requirements:

Option 1: Dedicated Servers

  • Physical servers dedicated solely to our operations (no shared tenancy)
  • Private network with no public exposure except via CDN
  • Full control over server configuration and security
  • UK data centres only
  • Suitable for clients requiring dedicated infrastructure

Option 2: Laravel Cloud (AWS)

  • Managed Laravel hosting platform built on AWS infrastructure
  • Auto-scaling and managed services
  • Automatic security patching
  • UK regions only (EU-West-2 London)
  • Suitable for clients requiring scalability and managed platform benefits

Both options provide:

  • UK-exclusive data residency
  • ISO 27001 certified infrastructure providers
  • Enterprise-grade security controls
  • 24/7 monitoring and support

We complement our hosting with:

  • AWS S3 - Secure object storage (UK regions only)
  • Cloudflare - CDN, DDoS protection, and web application firewall
  • GitHub - Secure code repositories and CI/CD

3.2 Our Responsibilities

Regardless of hosting option, we are responsible for:

  • Application security and development
  • Access control and authentication
  • Security monitoring and incident response
  • Database management and backups
  • Client communication and support
  • Server configuration

4. Data Protection & Sovereignty

4.1 Data Location

  • All client data hosted exclusively in United Kingdom regions
  • OVHcloud: UK data centres only
  • Laravel Cloud / AWS: EU-West-2 (London) only
  • AWS S3: EU-West-2 (London) only
  • No data replication outside UK jurisdiction
  • Compliance with UK GDPR and Data Protection Act 2018

4.2 Infrastructure Partners

Our infrastructure providers maintain the following certifications:

OVHcloud (Dedicated Servers)

  • ISO 27001:2013 - Information Security Management
  • ISO 27017 - Cloud Services Security
  • ISO 27018 - Protection of PII in Public Clouds
  • Tier III+ data centres with 24/7 physical security
  • Full details: https://www.ovhcloud.com/en-gb/compliance/

AWS (Laravel Cloud & Object Storage)

  • ISO 27001, ISO 27017, ISO 27018
  • SOC 1, SOC 2, SOC 3 (Type II)
  • PCI DSS Level 1
  • Full details: https://aws.amazon.com/compliance/
  • Shared Responsibility Model: AWS secures infrastructure; we secure applications

Laravel Cloud

  • Built on AWS infrastructure (inherits AWS certifications)
  • Managed by Laravel team with strong security track record
  • Automatic security patching and updates
  • UK region deployment only

Cloudflare

  • ISO 27001
  • SOC 2 Type II
  • PCI DSS Level 1
  • DDoS mitigation capacity: 172 Tbps

5. Security Controls

5.1 Encryption

In Transit:

  • TLS 1.3 (preferred) or TLS 1.2 (minimum)
  • HTTPS enforced for all connections via Cloudflare
  • Strong cipher suites only (weak ciphers disabled)
  • HSTS enabled with 1-year validity
  • Perfect Forward Secrecy (PFS) enabled
  • Automatic certificate management

At Rest:

  • Database encryption using AES-256
  • S3 bucket encryption (SSE-S3 or SSE-KMS)
  • Full disk encryption (OVHcloud servers)
  • Encryption keys managed securely (AWS KMS for S3)

5.2 Network Security

OVHcloud Dedicated Servers:

  • Private network with no public exposure except via CDN
  • Dedicated physical servers solely under our control
  • Firewall rules restrict access to known IPs only
  • No shared tenancy with other organisations

Laravel Cloud (AWS):

  • Application servers not directly exposed to internet
  • AWS VPC with private subnets
  • Security groups and network ACLs
  • Managed firewall by platform provider

Universal (All Hosting):

  • CDN Protection: Cloudflare provides DDoS protection (automatic, unlimited)
  • Web Application Firewall: OWASP Core Rule Set enabled
  • Rate Limiting: Application and edge-level rate limiting
  • SSL/TLS: End-to-end encryption

5.3 Access Control & Credentials

Production Access:

  • MFA (Multi-Factor Authentication) required for all access
  • SSH key-based authentication only (passwords disabled on OVHcloud)
  • Access restricted to Lloyd Owen (Technical Director) and authorized team members
  • All production access logged and monitored
  • Just-in-time access for specific tasks

Password Management:

  • 1Password used for all credentials and secrets
  • Strong unique passwords generated for every service (minimum 20 characters)
  • Credentials never stored in code or plain text
  • Shared vaults for team access where needed
  • Emergency access procedures documented
  • Regular password rotation for service accounts

Application Authentication:

  • Secure password hashing (bcrypt/Argon2)
  • Session management with httpOnly, secure, sameSite flags
  • CSRF protection on all state-changing operations
  • Optional 2FA for end users

Cloudflare Access:

  • Where possible, Cloudflare accounts are client-owned
  • We are granted team member access to client's Cloudflare account
  • Provides transparency and client control
  • MFA enforced on all Cloudflare accounts
  • Access revoked immediately upon project completion if required

5.4 Application Security

We follow OWASP Top 10 security practices:

  • Input validation and sanitisation
  • Parameterised queries (no SQL injection)
  • XSS prevention through output encoding
  • CSRF tokens on all forms
  • Security headers (CSP, X-Frame-Options, X-Content-Type-Options, etc.)
  • Dependency scanning for vulnerabilities
  • Regular security updates
  • Secure session management
  • Protection against brute force attacks

6. Backup & Recovery

6.1 Backup Strategy

Databases:

  • Point-in-Time Recovery: Can restore to any second of the day (continuous transaction log backups)
  • Automated Daily Backups: Full database backups at 02:00 UTC
  • Off-Site Storage: Nightly backups shipped to separate UK data centre (minimum 100km from primary)
  • Backup Retention:
    • Point-in-time recovery: 7 days
    • Daily backups: 30 days
    • Weekly backups: 12 weeks (3 months)
    • Monthly backups: 12 months
    • Annual backups: 7 years (where required by client contract)
  • Encryption: All backups encrypted with AES-256 before storage
  • Verification: Automated integrity checks on all backups
  • Testing: Monthly restore tests to verify backup integrity

Application Code:

  • Version controlled in private GitHub repositories (typically client's GitHub organisation)
  • Multiple redundant copies across GitHub's global infrastructure
  • Complete version history maintained
  • GitHub provides automatic geo-redundant storage
  • No separate code backups required (GitHub SLA sufficient)
  • Ability to redeploy any version within hours

Object Storage (S3):

  • S3 versioning enabled where specifically required by client
  • Standard S3 configuration: AWS's 99.999999999% (11 9's) durability SLA
  • Automatic multi-AZ replication by AWS
  • Cross-region replication configured only where specifically required
  • Deleted files can be recovered via versioning (where enabled)

Configuration & Infrastructure:

  • Infrastructure as Code (version controlled)
  • Server configurations documented and reproducible (OVHcloud)
  • Laravel Cloud configurations managed via platform dashboard
  • Environment variables and secrets stored in 1Password
  • Deployment configurations in Git repositories

6.2 Recovery Objectives

Component

RPO (Maximum Data Loss)

RTO (Maximum Recovery Time)

Database

Seconds (point-in-time recovery available)

2 hours

Application Code

Zero (GitHub versioning)

2 hours

Object Storage (S3)

Near-zero (AWS multi-AZ)

1 hour

Server Configuration

24 hours

4 hours

Complete Environment

24 hours

8 hours

Notes:

  • RPO/RTO are maximum targets; actual recovery often faster
  • Database point-in-time recovery allows restoration to any specific second within 7 days
  • Application redeployment typically takes 30-60 minutes
  • S3 relies on AWS's industry-leading durability and availability SLAs
  • Laravel Cloud benefits from AWS multi-AZ redundancy and automatic failover

7. Monitoring & Incident Response

7.1 Monitoring

  • Application Monitoring: Real-time error tracking and performance monitoring
  • Infrastructure Monitoring: Server uptime, resource utilisation, disk space
  • Security Monitoring: Failed login attempts, suspicious activity, unusual traffic patterns
  • Database Monitoring: Query performance, connection pooling, replication lag
  • Platform Health: Laravel Cloud dashboard monitoring (where applicable)
  • Log Retention: 90 days for application logs; 12 months for security logs

7.2 Incident Management

We use Slack + Incident.io for structured incident management:

Incident Classification:

  • P1 (Critical): Complete outage or confirmed security breach
    • Response: Immediate (within 15 minutes, 24/7)
    • Client notification: Within 1 hour
  • P2 (High): Significant degradation or suspected breach
    • Response: Within 2 hours
    • Client notification: Within 4 hours
  • P3 (Medium): Minor issues affecting limited functionality
    • Response: Within 8 hours (same business day)
    • Client notification: Within 24 hours
  • P4 (Low): Cosmetic issues or minor bugs
    • Response: Within 48 hours
    • Client notification: As appropriate

Incident Process:

  1. Detection: Automated monitoring or user report
  2. Triage: Severity classification and resource allocation
  3. Communication: Incident channel created in Slack/Incident.io
  4. Investigation: Root cause analysis
  5. Mitigation: Immediate actions to restore service
  6. Resolution: Permanent fix implemented
  7. Post-Mortem: Lessons learned and preventative measures (P1/P2 only)

Security Incident Response:

  • Security incidents treated as minimum P2 severity
  • Immediate containment and investigation
  • Client notification within 4 hours of confirmation
  • Forensic evidence preserved
  • Post-incident report within 7 days
  • Regulatory notifications handled as required (GDPR, etc.)

24/7 Availability:

  • Lloyd Owen (Technical Director) available 24/7 for P1/P2 incidents
  • Monitored via mobile alerts, email, and Slack notifications
  • Emergency contact: support@valoradev.com (monitored continuously)

8. Updates & Patch Management

8.1 Infrastructure Updates

OVHcloud Dedicated Servers:

  • Critical security patches: Applied within 48 hours
  • High priority patches: Applied within 7 days
  • Standard updates: Applied monthly during maintenance windows
  • Patches tested on non-production servers before production deployment

Laravel Cloud (AWS):

  • Operating system patches: Managed automatically by platform
  • Runtime updates (PHP, Node.js): Managed by platform with testing
  • Infrastructure security: Automatic updates by AWS and Laravel Cloud
  • Platform updates: Deployed by Laravel Cloud team with zero downtime

Server Software (OVHcloud):

  • Web servers (Nginx/Apache): Security updates within 7 days
  • PHP/Node.js runtimes: Security updates within 7 days
  • Database software: Security updates within 7 days (with testing)
  • System libraries: Regular updates during maintenance windows

8.2 Application Dependencies

Continuous Vulnerability Scanning:

  • Automated scanning every commit via GitHub Advanced Security
  • Real-time alerts for new vulnerabilities
  • Dependency scanning (npm, Composer, pip)
  • Secret scanning to prevent credential leaks

Update Timeline:

  • Critical vulnerabilities (CVSS 9.0-10.0): Within 48 hours
  • High severity (CVSS 7.0-8.9): Within 7 days
  • Medium severity (CVSS 4.0-6.9): Within 30 days
  • Low severity (CVSS 0.1-3.9): Next regular release cycle

Framework & Core Updates:

  • Laravel security patches: Within 48 hours of release
  • React security updates: Within 7 days
  • Minor version updates: Monthly during maintenance windows
  • Major version updates: Planned with client approval, comprehensive testing

9. Development Practices

9.1 Secure Development

Code Quality & Security:

  • Peer code review required for all production changes
  • Automated testing suite including security tests
  • Version control in private GitHub repositories (typically client-owned)
  • Secrets never stored in code (environment variables only)
  • Secure coding practices following OWASP guidelines

GitHub Advanced Security:

  • Dependabot: Automated dependency vulnerability alerts and updates
  • Code Scanning (CodeQL): Static analysis for security vulnerabilities
    • SQL injection detection
    • Cross-site scripting (XSS)
    • Command injection
    • Path traversal
    • Insecure randomness
    • And 150+ other security patterns
  • Secret Scanning: Prevents accidental credential commits
    • Scans for API keys, passwords, certificates
    • Real-time alerts if secrets detected
    • Partner tokens automatically revoked
  • Automated Pull Request Checks: Security gates before code merge
  • Supply Chain Security: Dependency graph and vulnerability tracking

9.2 Development Environments

Environment Separation:

  • Development: Local development environment
  • Staging: Replica of production for testing (separate servers/environment)
  • Production: Live client environment

Deployment Process:

  1. Code changes committed to feature branch
  2. Automated tests run (including security scans)
  3. Peer review via GitHub pull request
  4. Merge to staging branch
  5. Automated deployment to staging
  6. Testing and quality assurance
  7. Approval for production deployment
  8. Automated deployment to production
  9. Post-deployment verification

Rollback Capability:

  • Instant rollback to previous version via Git
  • Zero-downtime deployments where possible
  • Database migrations reversible
  • Automated health checks after deployment

10. Vulnerability Management

10.1 Continuous Monitoring

Automated Scanning:

  • Every Git commit scanned by GitHub Advanced Security
  • Dependency vulnerability checks on every pull request
  • Weekly infrastructure vulnerability scans (OVHcloud)
  • Platform security monitoring (Laravel Cloud)
  • Quarterly application security reviews

Vulnerability Sources:

  • GitHub security advisories
  • CVE (Common Vulnerabilities and Exposures) database
  • Vendor security bulletins (Laravel, AWS, OVHcloud)
  • Security research and threat intelligence

10.2 Annual External Testing

Third-Party Security Assessments:

  • Annual penetration testing by qualified external security firms
  • Scope: External-facing applications and infrastructure
  • Methodology: OWASP Testing Guide, PTES standards
  • Deliverables: Executive summary and detailed technical report
  • Remediation tracking until all issues resolved
  • Results available to clients (subject to NDA)

Vulnerability Assessment Process:

  1. Discovery and classification
  2. Risk assessment (CVSS scoring)
  3. Prioritization based on exploitability and impact
  4. Remediation planning
  5. Fix implementation and testing
  6. Verification and closure
  7. Lessons learned

11. Risk Management

11.1 Risk Assessment Approach

We conduct regular risk assessments using a structured methodology covering:

Information Security Risks:

  • Application vulnerabilities (OWASP Top 10)
  • Infrastructure security gaps
  • Access control weaknesses
  • Data protection risks
  • Third-party dependencies

Operational Risks:

  • Key person dependency
  • Service provider outages
  • Data loss scenarios
  • Disaster recovery capability

Compliance Risks:

  • GDPR compliance
  • Client regulatory requirements
  • Data residency obligations

Assessment Frequency:

  • Annual: Comprehensive risk review covering all areas
  • Quarterly: Risk assessment for new projects and significant changes
  • Ad-hoc: Assessment triggered by significant incidents or threat landscape changes
  • Post-Incident: Risk review following any P1 or P2 security incident

11.2 Risk Treatment Strategy

For each identified risk, we implement one of four treatment approaches:

1. Mitigation (Reduce likelihood or impact):

  • Implement security controls (MFA, encryption, monitoring)
  • Apply security patches and updates
  • Conduct regular security testing
  • Staff training and awareness
  • Examples:
    • MFA mitigates unauthorised access risk
    • Backups mitigate data loss risk
    • GitHub Advanced Security mitigates vulnerable dependency risk

2. Transfer (Share risk with third parties):

  • Cyber liability insurance
  • Professional indemnity insurance
  • Infrastructure provider SLAs
  • Contractual protections
  • Examples:
    • Insurance covers financial impact of data breach
    • AWS SLA covers infrastructure availability
    • OVHcloud covers physical data centre security

3. Acceptance (Acknowledge and document):

  • Low-impact risks with low likelihood
  • Risks where mitigation cost exceeds potential impact
  • Formally documented and approved by Technical Director
  • Regular review to ensure risk remains acceptable
  • Examples:
    • Risk of minor visual bugs in non-critical features
    • Risk of brief downtime during planned maintenance

4. Avoidance (Eliminate risk by not taking action):

  • Not implementing high-risk features without adequate controls
  • Declining projects outside our expertise
  • Not storing data types we cannot adequately protect
  • Examples:
    • Not implementing payment processing ourselves (use Stripe)
    • Not accepting projects requiring US data residency
    • Not storing biometric data or highly sensitive medical records

11.3 Current Risk Register

Risk

Likelihood

Impact

Rating

Treatment

Controls

Unauthorized production access

Low

High

Medium

Mitigate

MFA, SSH keys only, access logging, 1Password

Vulnerable dependencies

Medium

Medium

Medium

Mitigate

GitHub Advanced Security, Dependabot, automated scanning

Data loss (database)

Low

High

Medium

Mitigate

Point-in-time recovery, off-site backups, monthly restore tests

DDoS attack

Medium

Medium

Medium

Transfer

Cloudflare unlimited DDoS protection

Key person unavailable

Low

Medium

Low

Accept

Documentation, client access to GitHub, emergency procedures

Infrastructure provider outage

Low

Medium

Low

Transfer/Mitigate

AWS/OVHcloud SLAs, multi-AZ deployments, backups

Ransomware/malware

Low

High

Medium

Mitigate

Regular backups, antivirus, MFA, security monitoring

Accidental data deletion

Low

Medium

Low

Mitigate

Database versioning, S3 versioning, soft deletes in application

Social engineering attack

Low

Medium

Low

Mitigate

Security awareness training, 1Password, MFA

Supply chain attack

Low

High

Medium

Mitigate

GitHub Secret Scanning, Dependabot, code review, trusted vendors only

Risk Ratings:

  • High: Immediate action required, executive attention
  • Medium: Action required within defined timeframe, regular monitoring
  • Low: Acceptable with current controls, periodic review

11.4 Risk Review & Continuous Improvement

Quarterly Risk Reviews:

  • Technical Director reviews risk register
  • New risks identified and assessed
  • Existing controls evaluated for effectiveness
  • Changes in threat landscape considered
  • Risk treatment plans updated

Post-Incident Risk Assessment:

  • Every P1/P2 incident triggers risk review
  • Root cause analysis identifies control gaps
  • New risks or changed risk ratings documented
  • Additional controls implemented where justified

Annual Comprehensive Review:

  • Complete review of all risks and controls
  • Effectiveness metrics analyzed
  • Industry trends and emerging threats considered
  • Insurance coverage adequacy reviewed
  • Client feedback incorporated

Risk Communication:

  • High risks escalated to clients immediately
  • Significant risk changes communicated within 48 hours
  • Quarterly security summary provided to clients (on request)
  • Annual security posture report available

12. Data Retention & Disposal

12.1 Retention

  • Client Application Data: Retained per client contract (default: indefinite until deletion requested)
  • Database Backups: Per Section 6.1 (7 days to 7 years depending on type)
  • Application Logs: 90 days
  • Security Logs: 12 months
  • Source Code: Retained in client's GitHub repository (client controls retention)
  • Infrastructure Logs: 90 days

12.2 Secure Disposal

When data deletion is required:

Database Data:

  • Records deleted from production database
  • Delete operations propagate to replicas
  • Backups containing deleted data expire per retention policy
  • Point-in-time recovery expires after 7 days

Object Storage (S3):

  • Objects deleted (all versions if versioning enabled)
  • AWS handles secure deletion per their certified procedures
  • Permanent deletion confirmation available on request

Servers (End of Life):

  • Data securely wiped before decommissioning
  • OVHcloud: 3-pass overwrite minimum (DoD 5220.22-M)
  • Laravel Cloud: Managed by AWS with certified disposal procedures
  • Certificate of destruction available on request

Client Contract Termination:

  • 30-day grace period for client to retrieve data
  • Data export provided in standard formats (JSON, CSV, SQL)
  • After grace period, secure deletion initiated
  • Confirmation of deletion provided to client

13. Personnel Security

13.1 Team

Lloyd Owen - Technical Director

  • 10+ years experience in regulated industries (medical devices, financial services)
  • Responsible for all production access and security decisions
  • Available 24/7 for critical incidents
  • Background checked (DBS where required by client contract)

Development Team

  • Additional developers engaged on project basis
  • All developers undergo background checks before production access
  • Security awareness training required before system access
  • Code review required for all production changes
  • Access revoked immediately upon project completion

13.2 Security Training

Initial Training (Before System Access):

  • Information security policy review
  • OWASP Top 10 and secure coding practices
  • Password management (1Password)
  • Incident reporting procedures
  • GDPR and data protection basics

Annual Refresher:

  • Security policy updates
  • New threat landscape review
  • Lessons learned from incidents
  • Best practices review

Continuous Learning:

  • Security bulletins and advisories
  • Laravel security updates
  • GitHub security features training

13.3 Access Management

Access Principles:

  • Least privilege (minimum access required for role)
  • Just-in-time access (temporary elevation for specific tasks)
  • MFA required for all production access
  • All access logged and auditable

Access Review:

  • Quarterly review of all active access
  • Immediate revocation upon role change or departure
  • Client notification of access changes

1Password Security:

  • Master password never shared
  • Emergency Kit stored securely offline
  • Two-factor authentication enabled
  • Regular security audits via 1Password Watchtower

14. Business Continuity

14.1 Service Availability

  • Target Uptime: 99.9% (excluding scheduled maintenance)
  • Scheduled Maintenance: Sundays 02:00-06:00 GMT (48 hours notice)
  • Infrastructure Redundancy:
    • OVHcloud: Redundant power, networking, storage
    • Laravel Cloud: AWS multi-AZ deployments, auto-scaling
    • Cloudflare: Global anycast network, automatic failover
  • DDoS Protection: Unlimited automatic mitigation by Cloudflare

14.2 Disaster Recovery

OVHcloud Servers:

  • Off-site backups in separate UK data centre
  • Infrastructure as Code for rapid server rebuild
  • Documented recovery procedures
  • Estimated recovery time: 8 hours for complete environment

Laravel Cloud (AWS):

  • Multi-AZ deployment for automatic failover
  • AWS regional redundancy
  • Point-in-time database recovery
  • Estimated recovery time: 2-4 hours

Both Platforms:

  • Application code in GitHub (multiple redundant copies)
  • Database backups tested monthly
  • Annual disaster recovery exercise
  • Client notification procedures documented

14.3 Key Person Risk

Lloyd Owen Unavailability:

  • All code and infrastructure documented
  • Clients have access to GitHub repositories
  • 1Password emergency access procedures
  • Third-party specialist support available if needed
  • Critical client contacts maintained

15. Third-Party Services

15.1 Service Providers

Provider

Service

Certifications

Data Location

OVHcloud

Dedicated servers

ISO 27001, 27017, 27018

UK only

AWS

Laravel Cloud, S3, infrastructure

ISO 27001, SOC 2, PCI DSS

UK (London)

Cloudflare

CDN, DDoS, WAF

ISO 27001, SOC 2, PCI DSS

Global (UK PoP)

GitHub

Code repositories, CI/CD

ISO 27001, SOC 2

Global (geo-redundant)

1Password

Password management

ISO 27001, SOC 2

Global (encrypted)

15.2 Third-Party Management

Vendor Selection:

  • Security certifications required (ISO 27001 minimum)
  • GDPR compliance verified
  • Data Processing Agreements (DPA) in place
  • Regular security assessment reviews

Ongoing Monitoring:

  • Annual review of vendor certifications
  • Security incident notifications received
  • SLA compliance monitored
  • Alternative vendors identified for critical services

16. Compliance Support

16.1 Standards We Support

Our infrastructure and practices support clients requiring:

  • ISO 27001 - Information Security Management
  • UK GDPR / Data Protection Act 2018 - Data protection
  • Cyber Essentials - UK government baseline security
  • Industry-specific: FCA regulations, medical device regulations, etc.

16.2 Audit Support

Clients may request:

  • This security policy document
  • Infrastructure provider certifications
  • Access logs and audit trails
  • Penetration test results (subject to NDA)
  • Incident reports and post-mortems
  • Backup verification reports
  • Risk register and treatment plans

Response Time:

  • Standard requests: 5 business days
  • Urgent requests: 24-48 hours
  • Emergency requests: Same day

16.3 Data Processing

  • Data Processing Agreements (DPA) available
  • GDPR-compliant data processing
  • Data subject rights supported (access, rectification, erasure, portability)
  • Data breach notification within 72 hours (where required)
  • Privacy by design approach

17. Client Rights & Responsibilities

17.1 Client Rights

  • Access to your data at any time
  • Data export in standard formats (JSON, CSV, SQL)
  • Access logs on request
  • Security incident notifications
  • Right to audit (with reasonable notice)
  • Data deletion on request
  • Copy of this policy and related documentation

17.2 Shared Responsibility Model

We're Responsible For:

  • Infrastructure security (servers, network, platform)
  • Application code security
  • Database security and backups
  • Security monitoring and incident response
  • Patch management
  • Encryption implementation

Clients Are Responsible For:

  • User access management within application
  • Content uploaded to application
  • End-user password strength
  • Reporting security concerns promptly
  • Following security best practices
  • Maintaining their Cloudflare account security (where applicable)

18. Support & Emergency Contact

18.1 General Support

Email: support@valoradev.com
Response Times:

  • General inquiries: Within 24 hours (business days)
  • Technical issues (P3/P4): Within 48 hours
  • Urgent issues (P2): Within 2 hours
  • Critical issues (P1): Within 15 minutes (24/7)

18.2 Security Issues

For security concerns or incidents:

Email: support@valoradev.com (Subject: SECURITY)
Response: Within 4 hours
For P1 Security Incidents: Within 15 minutes (24/7)

18.3 What to Report

Please report immediately:

  • Complete service outages
  • Suspected security breaches or unauthorised access
  • Unusual system behaviour or error messages
  • Excessive failed login attempts
  • Data integrity concerns
  • Any security vulnerabilities discovered

When reporting, include:

  • Date and time of incident/observation
  • Systems or features affected
  • Description of the issue
  • Any error messages or screenshots
  • Impact on your users/business
  • Your contact information

19. Insurance & Liability

Lloyd IT Limited maintains:

  • Professional Indemnity Insurance - Errors and omissions coverage
  • Cyber Liability Insurance - Data breach and security incident coverage
  • Public Liability Insurance - General business liability

Coverage details and policy certificates available upon request for audit and compliance purposes.

20. Policy Review & Updates

20.1 Review Schedule

  • Annual Review: Comprehensive review every December
  • Quarterly Check: Minor updates and corrections (March, June, September)
  • Ad-hoc Updates: Following significant incidents, infrastructure changes, or regulatory updates

20.2 Document Control

  • Current Version: 1.0
  • Effective Date: December 2024
  • Next Review: December 2025
  • Owner: Lloyd Owen, Technical Director
  • Distribution: Public document, available at https://valoradev.com