Trust & Security Centre

← Back to Home

1. Overview

At MatjarUK, security and data protection are foundational to our platform, not afterthoughts bolted on. Our retail clients trust us with inventory data, order flows, and supplier relationships — and we take that responsibility seriously at every layer of our architecture.

This Trust Centre outlines our security practices, infrastructure, incident-response procedures, and compliance commitments. We encourage prospective and existing clients to review this document and contact us with any questions at security@matjaruk.com.

2. Trust Pillars

3. Security Practices

3.1 Access Controls

• Role-based access control (RBAC) enforced across all internal systems and the client-facing platform
• Principle of least privilege — team members and automated services receive only the permissions necessary for their function
• Multi-factor authentication (MFA) mandatory for all internal access; strongly recommended for client accounts
• Access reviews conducted quarterly; unused accounts deactivated automatically after 90 days

3.2 Data Protection

• All personal data encrypted at rest (AES-256) and in transit (TLS 1.3)
• Database access restricted to application-layer services; no direct database access for human operators
• Backups encrypted and stored in a geographically separate AWS region
• Data retention policies enforced automatically (see Privacy Policy §8)

3.3 Application Security

• Automated dependency scanning on every build (Dependabot + Snyk)
• Static analysis integrated into CI/CD pipeline
• Annual third-party penetration testing
• Secure development lifecycle training for all engineering staff

4. Infrastructure Details

4.1 Cloud Hosting

• Provider: Amazon Web Services (AWS)
• Region: eu-west-2 (London)
• Architecture: Multi-AZ deployment with auto-scaling groups
• Networking: VPC isolation, private subnets, WAF-protected public endpoints

4.2 Email Delivery

• Provider: Mailgun (Sinch)
• Configuration: Dedicated sending IP address
• Authentication: SPF + DKIM + DMARC (p=reject)
• Daily volume: ~9,900 transactional messages
• Complaint rate: < 0.03% (target < 0.05%)
• Bounce rate: < 1.4% (target < 2%)
• Suppression list: Enforced synchronously on every send request

5. Incident Response

Our incident-response process follows a structured five-phase approach:

1. Detection (0–15 minutes) — Automated monitoring surfaces anomalies; PagerDuty alerts on-call engineer
2. Triage (15–60 minutes) — Severity assessment and incident commander assignment
3. Containment (1–4 hours) — Isolate affected systems, preserve forensic evidence
4. Remediation (4–24 hours) — Root-cause analysis, patch deployment, system restoration
5. Post-Incident Review (within 5 business days) — Blameless retrospective, lessons-learned document, preventive measures implemented

GDPR notification: Supervisory authorities are notified within 72 hours of confirming a personal data breach. Affected data subjects are notified without undue delay where the breach poses a high risk to their rights.

6. Logging & Audit Trail

• Email delivery logs — retained for 90 days (recipient, timestamp, status, bounce/complaint codes)
• System access logs — retained for 12 months (user, action, timestamp, IP address)
• Template change logs — retained for 24 months (actor, diff, approval status)
• Infrastructure logs — retained for 12 months (AWS CloudTrail, VPC Flow Logs)
• All logs are append-only and stored in tamper-evident storage
• Change management process requires dual-approval for any modification to email templates or sending rules

7. Compliance

MatjarUK is committed to compliance with the following regulatory frameworks:

• GDPR — General Data Protection Regulation (EU/UK)
• CCPA — California Consumer Privacy Act
• CAN-SPAM Act — US federal email regulation
• CASL — Canada's Anti-Spam Legislation

We maintain internal compliance documentation and cooperate fully with regulatory enquiries. Our Privacy Policy and Acceptable Use Policy provide further detail.

8. Email Practices (Detailed)

This section provides an in-depth view of our email sending practices, supplementing the summary on our homepage.

8.1 Recipient Verification

Every recipient address undergoes a multi-step validation before the first message is dispatched: syntax validation, MX record lookup, role-address detection, and disposable-domain filtering. Addresses failing validation are rejected at registration time.

8.2 Suppression List

A platform-wide suppression list is maintained in real time. It contains hard-bounced addresses, complaint-generating addresses, manual opt-outs, and addresses flagged through feedback loops. The list is consulted synchronously before every send — no message leaves our infrastructure without passing this check.

8.3 Bounce & Complaint Workflows

• Hard bounces → immediate, permanent suppression
• Soft bounces → three retry attempts across 48 hours; if all fail, address is permanently suppressed
• Complaints → instant suppression; the client success team is notified within 1 hour to review the sending template and recipient provenance

8.4 Feedback Loop (FBL) Monitoring

We subscribe to all major ISP feedback loops. FBL reports are consumed and processed within minutes. The complaining address is suppressed, and the associated email template is flagged for compliance review.

8.5 Rate Limiting & Anomaly Detection

Each client has per-hour sending caps calibrated to their plan tier. If a client's sending volume exceeds 200% of their 7-day rolling average, automatic throttling engages and an engineering alert is triggered.

8.6 Sending Access Control (RBAC)

Only designated system services and users with the ops-admin role can trigger outbound email. Manual overrides require approval from a second authorised user. API keys for sending are rotated every 90 days.

8.7 Template Change Approvals

All email template changes — subject lines, body content, recipient targeting rules — go through a dual-approval workflow. Changes are versioned and diffed; the full history is available in the audit trail.

8.8 Audit Trail

Delivery logs are retained for 90 days. Template change logs for 24 months. Access and permission change logs for 12 months. All are stored in append-only, tamper-evident storage.

8.9 Reporting Abuse

If you believe you have received an unwanted message from our platform, or wish to report abuse, please contact abuse@matjaruk.com. We investigate all reports within 24 hours.

9. Responsible Disclosure

We welcome responsible security research. If you discover a vulnerability in our platform:

• Email security@matjaruk.com with a detailed description and proof of concept
• We will acknowledge receipt within 48 hours
• Assessment and initial response within 5 business days
• We will not pursue legal action against researchers acting in good faith
• Credit is given to researchers upon remediation (with consent)

10. Contact

For questions about our security practices or to discuss compliance requirements:

• Security: security@matjaruk.com
• Privacy: privacy@matjaruk.com
• Abuse: abuse@matjaruk.com
• MatjarUK Technologies, Inc.
• 2614 Westheimer Rd, Suite 210, Houston, TX 77098
• Phone: +1 (713) 482-7190