Purpose

Set minimum security expectations for people, systems, and data used by Ghida Alsultan Co, across SaaS and local systems, to preserve confidentiality, integrity, and availability.

Policy

• Applies to all employees, contractors, and vendors who access organizational data or systems.
• Covers SaaS platforms (e.g., Odoo), on‑premises services (e.g., POS), networks, and endpoints.
• References good practices (ISO 27001, NIST CSF) and applicable legal/contractual terms.

This policy establishes minimum security requirements for all information systems, data, users, contractors, and third parties engaged by [Your Organization Name]. It applies to on‑premises, cloud, and SaaS environments, covering endpoints, network, applications, and data.

• Purpose: protect confidentiality, integrity, and availability of organizational information assets.
• Scope: all employees, contractors, and vendors accessing Internal, Confidential, or Restricted data.
• Standards & references: ISO/IEC 27001/27002, NIST CSF, and applicable laws (e.g., GDPR, KSA PDPL, PCI DSS, local labor/finance records).

Note: See the “Top 50” and “Follow‑ups” source questionnaires for the detailed prompts this policy is based on.

Purpose

Define ownership, approval, and review responsibilities so policy stays current and enforceable.

Policy

• Owner: Ghida Alsultan IT Department. Approvers: IT, COO, CEO. Reviewers: IT (annual).
• Maintain a current list of covered systems, owners, and periods in the Systems table.
• Keep security and privacy commitments aligned with vendor contracts and local laws.

Based on your answers: Department = IT Department of Ghida Alsultan Co; Owner = Ghida Alsultan IT Department; Approvers = IT/COO/CEO.

Policy & Procedure

1. The person who needs a change submits an email request to the IT Manager.
2. The IT Manager reviews the request, studies its feasibility and cost.
3. If the change is viable, the IT Manager raises the request to the Chief Operating Officer (COO) for approval.
4. If the COO approves, the change is implemented by the IT team or outsourced if needed.

Purpose

Establish a structured approach to identifying, evaluating, and mitigating risks to information systems and data.

Policy

• Risk assessments are performed annually and after major system updates or changes.
• The IT Department leads risk assessments using recognized methodologies (ISO 27001).
• Assessments include asset identification, threat and vulnerability analysis, risk evaluation, and mitigation planning.
• Findings are documented in a risk register and reported to management; high risks require mitigation plans and follow-up.
• Risk assessment results inform updates to policies, controls, and incident response plans.

Risk assessments are scheduled once a year or after major updates, ensuring ongoing risk management and compliance.

Purpose

Describe acceptable use of company IT resources to reduce misuse, data loss, and operational risk.

Policy

• Use company systems for business; limited personal use allowed if it does not interfere or break rules.
• Do not share passwords, bypass controls, or install unapproved software.
• Report incidents promptly using the Incident Report form.

Company IT resources are provided to conduct business. Limited personal use is permitted when it does not interfere with duties, consume excessive resources, or violate policy or law.

• Do: use approved systems, protect credentials, report incidents promptly, and follow data handling rules.
• Don’t: share passwords, install unapproved software, disable security controls, or misuse company data/systems.
• Monitoring: company may monitor usage consistent with local laws and contracts.

Adapted from policy_full.html: Acceptable Use statement.

Purpose

Ensure people get appropriate access for their role and lose it when no longer needed.

Policy

• Accounts are created on join and revoked on HR notification; user identities are local to each application.
• MFA is required for Odoo (Authenticator app).
• Access reviews occur every 6 months by the relevant owners.
• Shared accounts (e.g., Finance) must be documented with owners and usage scope.

• Unique identities are used across systems (email ID where supported; employee ID for POS). Accounts are created on join and terminated when HR notifies IT.
• Onboarding/offboarding: currently manual via IT form; no automation with HR. Deprovisioning occurs upon HR notification.
• User identities are local to each application and created manually.
• MFA: enabled for Odoo using an authenticator app. Other systems do not currently enforce MFA.
• Access reviews: conducted every 6 months; last period had new joiners only, no privilege changes.
• Shared accounts: exist in Finance (4 users share 2 accounts, pairs).

Based on your answers: local/manual accounts; MFA only for Odoo; 6‑monthly reviews; shared accounts in Finance.

Purpose

Rely on platform password settings that balance usability and security.

Policy

• Use platform defaults for password complexity; Odoo enforces "3 of 4" character classes (uppercase letters, lowercase letters, numbers, symbols).
• System‑to‑system secrets are managed per application; no centralized secrets manager at present.

• Complexity: Odoo requires passwords to contain at least three of four categories: uppercase A‑Z, lowercase a‑z, digits 0‑9, and symbols (e.g., ! @ # $ %).
• We rely on their enforcement; no additional overlay (e.g., custom password filter) is applied today.

Based on your answers: accept platform defaults; Odoo enforces 3‑of‑4 (upper, lower, number, symbol).

Purpose

Maintain awareness of devices and handle lost/stolen cases to reduce data exposure risk.

Policy

• Asset inventory is recorded in the ERP Assets module.
• BYOD allowed for top management for report viewing; device use must follow Acceptable Use.
• FDE/EDR are not mandatory at this time.
• Lost/stolen devices are reported using the Lost/Stolen Device Report form.

• Asset inventory: recorded in the Assets module within the ERP.
• FDE/EDR: not required today; most systems are SaaS and devices are used primarily for access.
• BYOD: allowed for top management for report review.
• Lost/stolen devices: report using the Lost/Stolen Device Report form in the Forms section.

Based on your answers: ERP asset module; no EDR/FDE requirement; limited BYOD; lost/stolen reported via form.

Purpose

Define baseline controls for network access and connectivity.

Policy

• No VPN/remote admin is required; local access to on‑prem systems.
• Fortinet firewall and switches are used with default security settings.
• Wireless uses WPA2 security; guest devices share the same NAT (no separate guest VLAN).
• Only required SQL Server ports for in‑house systems are exposed; exposure is tied to Dynamic DNS records.
• (Default SQL Server ports 1433 and 1434 only are opened externally.)
• Firewall is configured to immediately block the source after a single failed connection/authentication attempt.

• Internet access is via Fortinet firewall and switches; no static public IPs; used primarily for cloud access and browsing.
• No VPN or remote admin is required; only local access to on‑prem systems.
• Firewall settings are the platform defaults and rarely changed.
• Wireless security: WPA2 in use. Guest devices share the same NAT; no separate guest VLAN.
• Exposure policy: only SQL Server ports necessary for in‑house systems are open, and they are published using Dynamic DNS.
• Port specifics: only default SQL Server ports 1433 (TCP) and 1434 (UDP/browser service) are exposed.
• Abuse protection: the firewall blocks the source after the first failed attempt to connect or authenticate.

Based on your answers: Fortinet edge; no VPN; defaults active; WPA2; guests on same NAT; only SQL Server ports 1433/1434 via Dynamic DNS; block on first failed attempt.

Purpose

State the current approach to protecting data at rest and in transit, and how long backups are kept.

Policy

• Encryption relies on SaaS provider defaults.
• In‑house database backups are retained for up to 3 years.
• Backups of devices for departing employees are taken and retained under IT custody.

• Encryption: rely on provider defaults for SaaS.
• Retention & secure deletion: in‑house database backups are retained for up to 3 years. For departing employees, a backup of the assigned device is taken and retained under IT custody.

Based on your answers: provider‑managed encryption; defined retention for in‑house DBs (3 years) and leaver device backups.

Purpose

Ensure the ability to recover critical services and data within acceptable timeframes.

Policy

• POS (SQL Server) backup runs daily at 06:00 to disk and syncs to a local FTP server; manual cloud FTP copies as needed.
• Backups are accessible by the IT Manager; backups are not encrypted.
• Service recovery targets: RTO 4 hours, RPO 24 hours.
• Restore testing occurs during maintenance activities as needed; DR Quick Action and Backup Test forms are available.

• SaaS products: provider is responsible for platform backups and availability.
• In‑house POS (SQL Server): daily backup at 06:00 to a separate disk on the DB server; automatically synced to a dedicated local FTP server.
• Offsite copy: a secondary cloud‑based FTP server receives manual copies from time to time.
• Access to backups: IT Manager only; backups are not encrypted.
• RTO: 4 hours; RPO: 24 hours. Recovery process involves troubleshooting, then rebuild/restore to nearest backup if needed.
• Restore testing: happens during day‑to‑day maintenance rather than as scheduled tests.

Based on your answers: SaaS provider responsibility; POS daily 06:00 backups to disk + local FTP; manual cloud copy; IT Manager access only; tests ad‑hoc; RTO 4h/RPO 24h.

Purpose

Provide a simple path to report and respond to incidents to reduce impact.

Policy

• Incidents are raised via the ticketing system; emergency phone escalation is allowed.
• A full IR playbook is desired; until then, use the Incident Report form and team coordination.

• IR plan: not documented yet; a full IR playbook is desired.
• On‑call: incidents are raised via the ticketing system and handled by the IT team; in emergencies, users may call an IT member to expedite resolution.

Based on your answers: full playbook requested; ticket/phone support.

Purpose

Capture minimal expectations for vendor due diligence aligned with current practices.

Policy

• Vendor due diligence is based on contract reviews at signing.
• The Vendor Security Checklist form may be used for future onboarding.
• API keys are stored in databases as implemented by applications.

• Vendor due diligence: not performed today; rely primarily on contract review at signing.
• Use the Vendor Security Checklist in Forms for future onboarding.
• Contracts: reviewed at signing for security/privacy clauses.
• API keys: stored in DB.

Based on your answers: no formal vendor assessment; contracts reviewed; API keys in DB.

Purpose

Define basic physical safeguards and training expectations.

Policy

• Fingerprint access and cameras are in use; camera footage ≈30 days; biometric logs sync to BioTime.
• Removable media are not restricted at this time (server room/datacenter access controlled).
• Training is delivered 1:1 by IT with a checklist and signature.

• Access controls: fingerprint device and cameras in use. Camera footage retained ~30 days; biometric logs sync to BioTime server continuously.
• Removable media: not restricted currently.
• Training: delivered 1:1 by IT member using a checklist; employee signs after training. Annual policy review by IT Manager and upper management.

Based on your answers: fingerprint/camera in place; removable media open; training is 1:1 with sign‑off; annual governance review.

Purpose

Provide simple checklists and templates to operationalize the policy and collect evidence for audits.

Policy

• Use the embedded forms for incidents, access requests, shared accounts, DR checks, backup tests, vendor checklist, and lost/stolen device reporting.
• Forms may be exported as JSON or printed for signatures.

Use these forms to operationalize the policy. Submit digitally (export) or print for signatures. Required fields are marked.