Information Security Policy

Document: ARD-P13  ·  Revision: 0.2 (Draft)  ·  Draft Date: 11/11/2026

Purpose

Protect the confidentiality, integrity and availability of MoboCheck and client information. Set clear security ownership, controls and response requirements across Ardroid FZCO.

Scope

Applies to all employees, contractors, devices and service providers with access to MoboCheck or Ardroid information. Coverage includes desktop stations (Windows/macOS), mobile apps (iOS/Android), cloud services, APIs, back office, code, credentials, records and backups.

Clients own the security of their local computers and networks. Ardroid owns the software it distributes and information received or stored in its cloud.

Responsibility

• Management – Abdullah Iltaf: Approves the policy, funds controls and accepts material risks and exceptions.
• Information Security Officer (ISO) – Sajjad Awan: Maintains the security risk register, access reviews, incident response and quarterly management reporting.
• Data Privacy Lead – Sajjad Awan: Oversees personal data, privacy requests and legal obligations.
• Engineering Lead – Ehsan Ullah Tariq: Owns secure development, changes, production security and recovery.
• All personnel: Use approved access, complete training and report suspected incidents immediately.

A change owner cannot approve and deploy the same production change. Where staffing prevents segregation, a second person must review and record the change after release.

Definitions

• Client data: Information generated by MoboCheck for a customer, including tester accounts, device identifiers, diagnostics, grades, erase records and related logs.
• Security incident: Actual or suspected unauthorized access, disclosure, loss, alteration or disruption of information or systems.

General Requirements

Access is need-to-know. Client information remains confidential. Security controls, incidents, exceptions and evidence are documented and reviewed. This policy aligns with Ardroid’s existing QEH&S and R2v3 processes and uses ISO/IEC 27001 as a reference; it does not claim ISO/IEC 27001 certification.

Procedures/Process

1. Information Classification and Data

MoboCheck records account names, email, role and station; device identifiers and attributes (IMEI, serial, UDID, Wi-Fi MAC, model, capacity, carrier, lock status); and diagnostic, grading and erase results. It does not intentionally collect owners’ contacts, photos, messages, payment details or address data. New data fields require Privacy Lead approval.

Diagnostic logs read from a phone during testing stay on the station computer and are deleted automatically after 30 days. Station logs that testers upload for support are stored in AWS S3 (section 6).

2. Access and Authentication

• Identity: Use individual accounts and least-privilege roles. No shared access to production, cloud, databases or repositories.
• MFA: Required for company email, source control, cloud consoles and production administration.
• Lifecycle: Security Officer approves access; planned leavers lose access on their final working day, unplanned departures within 24 hours.
• Review: Review production and client-data permissions every quarter; remove unused access.
• Client and support access: Clients control tester accounts. Disable an account within one working day of a valid request. Staff access client records only for authorized support; log each access.

3. Encryption and Credential Protection

• Transport: Use HTTPS with TLS 1.2 or later for all station, app, API and cloud connections.
• Storage: Encrypt the cloud database, file storage and backups at rest using the hosting provider’s encryption.
• Passwords and sessions: Use salted bcrypt password hashes and signed, time-limited session tokens.
• Secrets: Keep keys and credentials in protected settings or a secrets store. Mask them in all logs; rotate exposed keys and credentials at separation as needed.
• Updates: Verify desktop update hashes before installation. Digitally signed updates remain a required improvement until implemented.

4. Development and Change Control

• Build: Separate test and production environments; never use live client data for development.
• Control: Keep code in private repositories. Track, review and test changes before deployment, with the small-team exception described above.
• Release: Record version numbers and release notes. Preserve tested rollback steps; the desktop app should revert after two failed starts where supported.
• Dependencies: Check third-party libraries for known vulnerabilities monthly; resolve critical findings within 30 days.
• Design: Review privacy impact and data minimization before adding features that process personal information.

5. Production Security and Monitoring

6. External Providers and Sub-Processors

Security Officer reviews providers before they receive client data and at least annually. Contracts must address data protection, access and incident handling. Notify clients of new sub-processors within the confirmed contractual notice period (draft: 30 days).

Maintain providers in the approved External Provider List (ARD-F10) and follow ARD-P11.

7. Incident Response

1. Report suspected security events immediately to the Security Officer, [email protected] or [email protected]. Clients use the same addresses.
2. Assess impact and severity. Open an incident record, including affected clients and data.
3. Contain access, accounts, hosts and keys; preserve evidence and a clear event timeline.
4. Notify affected clients within 24 hours of confirmation: what happened, which data, what was done and who to contact. Notify regulators where required by law or contract.
5. Recover from trusted systems and verify monitoring before restoring full service.
6. Complete a root-cause review and corrective actions within 10 working days; management approves closure.

Record incidents and near misses for at least 3 years. Rehearse incident response annually. Use ARD-P04, ARD-F04 and ARD-F04a for incident and corrective-action evidence.

8. Backup and Business Continuity

• Backups: Back up the cloud database daily, encrypted, and keep backups for 7 days in a location separate from production.
• Recovery: Recovery time objective: 4 to 8 hours after a major outage. Recovery point objective: 24 hours.
• Tests: Restore a backup to an isolated test environment quarterly and retain evidence.
• Stations: Testing continues through a short cloud outage: each station keeps a local database and retries its cloud updates when service returns.
• Ownership: Maintain documented recovery steps and at least two authorized people who can restore service.

See Business Continuity Management Policy (proposed ARD-P12). A separate, detailed recovery plan with escalation contacts remains to be created and approved.

9. Retention and Disposal

Securely sanitize company media before reuse or disposal. Keep evidence of device erasures under Ardroid’s established sanitization procedure and applicable contractual retention obligations.

10. People, Equipment and Physical Access

• People: Perform lawful pre-employment screening, obtain confidentiality agreements and provide annual security and privacy training.
• Company devices: Require full-disk encryption, auto-updates, anti-malware and a five-minute screen lock. Report missing devices immediately.
• Personal devices: Permit MFA-protected email and chat only; do not store client records or production keys locally.
• Assets and premises: Maintain a register of devices, software and cloud accounts. Lock offices after hours and escort visitors.

11. Compliance, Risk and Review

• Applicable obligations: Follow UAE data protection rules, Saudi PDPL where applicable and the data-security terms of client contracts. Track obligations under ARD-P02.
• Risk: Review security risks, owners and target dates with management quarterly.
• Exceptions: Require written management approval, reason, owner, mitigation and expiry date. Record and track each exception.
• Review: Review annually and after major incidents, material legal changes or architecture changes. Handle revisions under ARD-P01.

Records

Security risk register; access approvals and reviews; training records; change/release records; patch and vulnerability findings; penetration-test reports; incident records; backup/restore tests; approved provider list; management review minutes and approved exceptions. Retain per ARD-P01 and applicable contracts.

Approval (Pending)

Effective only after management approval. Until then, this document remains a draft.

Revision History

©Ardroid