Information Security Policy

Scope and mandatory use

These rules apply to the owner and anyone handling orders, payments, business accounts, devices, or website changes for AIOR Threads LLC. Online payments use Clover Hosted Checkout and PayPal; mobile payments use Clover Go on the owner’s phone. The merchant website handles order information and payment references, while approved payment services collect card details. New devices, payment methods, or data handling require a scope review before use.

All applicable PCI DSS v4.0.1 clauses are binding requirements of this policy, including those not restated verbatim here. The twelve sections below define operating rules and required evidence; they are a control-family map, not a completed clause-by-clause assessment. The owner must document actual applicability, provider responsibilities, evidence, gaps, and remediation against the assigned questionnaire. A “not applicable” decision requires a documented reason and supporting evidence; outsourced controls require verified provider coverage.

Coverage map

Each section is a policy requirement, not a claim that the listed evidence has already been collected.

1. Network protection

PCI DSS 1.1–1.5 · Responsible: Owner; hosting/network provider for controls it operates

• Maintain an inventory of business networks, connected payment devices, permitted connections, and responsible providers. Document where payments enter the provider environment and which business systems can affect checkout.
• Allow only necessary network traffic and authorized services. Keep payment-related systems separated from guest or public networks. Protect phones and computers that connect to both trusted and untrusted networks.
• Approve network-control changes before use, retain configuration records, and review relevant firewall and connection rules at least every six months. Obtain evidence for provider-managed controls; outsourcing is not a reason to assume completion.

Keep privately: Network and payment-flow diagrams, approved connections, network-control reviews.

2. Secure device and system settings

PCI DSS 2.1–2.3 · Responsible: Owner; authorized technical support

• Inventory phones, computers, applications, services, and wireless equipment used for business. Use supported software, change default passwords, disable unnecessary accounts and services, and document secure settings before systems enter service.
• Use screen locks, device encryption and secure remote administration. Keep personal or guest activities separate from payment administration. Do not use rooted or jailbroken phones or install software from untrusted sources.
• Protect business Wi-Fi with current encryption and unique administrator credentials. Update access credentials after personnel changes or suspected exposure. Review settings after material changes and at the annual scope review.

Keep privately: Device inventory, hardening checklist, configuration review records.

3. Stored payment and customer information

PCI DSS 3.1–3.7 · Responsible: Owner; payment providers for card data they hold

• AIOR Threads prohibits storing full card numbers or sensitive authentication data in its website database, email, chat, logs, photos, spreadsheets, or paper notes. Never retain security codes, full track data, or PIN information after authorization, even encrypted. Use transaction IDs and masked card references for business records.
• Route card entry directly to approved payment-provider interfaces. Do not export full card numbers. If unexpected card data is found, restrict access, notify the owner, preserve incident evidence without duplicating the data, investigate its origin, and arrange secure removal through the incident process.
• Keep order records only for documented fulfillment, dispute, and lawful business-record purposes. The owner must set retention periods, locations, and deletion owners in a private schedule before treating retention controls as complete. Review stored data at least quarterly and delete unnecessary records and copies.
• Any proposed exception involving stored card numbers must be reviewed before collection, with documented PCI scope, unreadable storage, key lifecycle procedures, restricted key custody, and required assessment. No such exception is authorized by this policy.

Keep privately: Data inventory, retention schedule, quarterly cleanup record, provider responsibilities.

4. Protected transmission

PCI DSS 4.1–4.2 · Responsible: Owner; website and payment providers

• Use strong, current encryption and valid trusted certificates for payment and administrative connections across public networks. Reject invalid certificates and insecure endpoints. Maintain an inventory of relevant certificates and encryption settings and review them at least annually.
• Never ask customers to send card details by email, text, social messages, or website contact forms. Do not manually relay card information between systems. Confirm provider-hosted checkout destinations after changes and investigate unexpected redirects immediately.

Keep privately: HTTPS/certificate checks, approved payment endpoints, provider evidence.

5. Malware and phishing protection

PCI DSS 5.1–5.4 · Responsible: Owner; endpoint/provider administrators

• Use supported anti-malware protection on susceptible systems, with current updates, active protection, logging, and scheduled scans. Users must not disable protection; temporary exceptions require owner authorization, a time limit, and compensating safeguards.
• For environments that do not support conventional anti-malware, document the technical limitations and a periodic malware-risk evaluation with a justified review frequency. Apply vendor security controls and reassess when threats or technology change.
• Use phishing protections where supported. Train authorized users to verify payment, password-reset, and support requests through known channels and report suspicious messages without opening attachments or providing credentials.

Keep privately: Protection settings, update/scan records, documented device-risk evaluation.

6. Secure website development and changes

PCI DSS 6.1–6.5 · Responsible: Owner; authorized website developer/provider

• Track third-party software and dependencies and monitor trusted vulnerability notices. Rate vulnerabilities by risk. Apply critical and high-security patches within one month of release; address others on documented risk-based schedules. Maintain a supported-technology plan.
• Use secure coding practices, server-side validation, access checks, protected configuration, and reviewed changes. Keep development and production separate; use test payment data and test credentials only in testing. Remove test accounts and data before release. Never put private payment tokens in public code, logs, or version control.
• Record the purpose, impact, authorization, tests, and rollback plan for changes. Review bespoke code for security weaknesses before release and train developers on relevant attack risks at least annually.
• Protect public web applications using the controls required by the applicable assessment, including automated attack protection where required. For payment-page scripts within scope, keep an inventory and business justification, authorize each script, and verify integrity. Assess iframe or redirect integrations using the current eligibility rules; a hosted payment service does not by itself validate the merchant website.

Keep privately: Software inventory, vulnerability tracking, reviews, change approvals, script inventory.

7. Access according to job responsibilities

PCI DSS 7.1–7.3 · Responsible: Owner

• Document which roles may view orders, issue refunds, change products, administer payment accounts, or publish code. Deny access by default and grant only the minimum required privileges with owner approval.
• Review user access at least every six months and after role changes; AIOR Threads additionally reviews administrator access every three months. Review application and system-account privileges at a risk-based documented frequency. Remove unnecessary access promptly and immediately revoke access when personnel leave.
• Do not give contractors unrestricted or permanent administrator access. Limit support access to approved tasks and periods, monitor it, and remove it after completion.

Keep privately: Role/access list, approvals, access reviews, removal records.

8. Individual accounts and authentication

PCI DSS 8.1–8.6 · Responsible: Owner; account providers

• Use unique individual accounts for people. Shared credentials are prohibited except documented exceptional cases permitted by the applicable standard with individual accountability. Use multi-factor authentication for administrative and remote access and all other in-scope access required by the assessment; a provider limitation must be recorded as a gap, not treated as compliant.
• Use unique strong passwords or passphrases and a password manager. For password-based in-scope systems, enforce at least 12 characters where supported (at least eight if the system cannot support 12), appropriate character complexity, and no reuse of the last four passwords. Apply the applicable password-change or dynamic risk-analysis requirements; single-factor password access requires the applicable 90-day change or equivalent permitted protection.
• Limit repeated failed logins to no more than ten before lockout for at least 30 minutes or verified administrator release where these controls apply. Require reauthentication after no more than 15 minutes of in-scope session inactivity and disable inactive user accounts within 90 days. Verify identities before password resets.
• Inventory service accounts, API keys, and webhook secrets; restrict their privileges and protect them in server-side secret storage. Avoid interactive login with service accounts, document exceptions, and rotate secrets at risk-based intervals and immediately following suspected exposure. Do not publish recovery codes or approval signatures.

Keep privately: Account inventory, MFA settings, authentication configuration, service-account controls.

9. Physical protection

PCI DSS 9.1–9.5 · Responsible: Owner; relevant hosting/payment providers

• Keep phones, computers, backups, and sensitive paper records under authorized control or in locked storage. Restrict visitors from sensitive work areas and supervise access. Maintain the applicable authorization and visitor records for any physical card-data environment.
• Maintain a register of payment devices and follow the provider’s tampering and substitution inspection instructions. Establish inspection frequency through a documented risk assessment. For the phone-only setup, inspect the phone and official app for unauthorized changes, unexpected prompts, or loss of control. Reassess this procedure before adding a reader.
• Do not print full card numbers. Restrict any sensitive media, track authorized movement, protect offsite storage, and securely erase or destroy it when no longer needed. Report lost devices immediately and use authorized remote lock/wipe procedures while preserving relevant incident evidence.

Keep privately: Device register, custody/inspection records, media handling and disposal records.

10. Logging and monitoring

PCI DSS 10.1–10.7 · Responsible: Owner; hosting/payment providers for their logs

• Identify available security and administrative logs for website hosting, payment accounts, access changes, and relevant devices. Capture attributable events with accurate timestamps, protect them from unauthorized modification, and restrict access. Never log card numbers, security codes, passwords, or private tokens.
• For systems subject to Requirement 10, review security events and critical-system logs daily using automated review mechanisms where required; review other logs at the documented risk-based frequency. Investigate anomalies and failed security controls immediately.
• Retain in-scope audit history for at least twelve months, with the most recent three months readily available, and synchronize system time. Verify provider-managed retention and review responsibilities. Record unavailable logs, retention gaps, or monitoring limitations for remediation rather than claiming they are in place.

Keep privately: Log-source inventory, review records, alert response, retention and time settings.

11. Security testing and tamper detection

PCI DSS 11.1–11.6 · Responsible: Owner; qualified testing providers and hosting provider as applicable

• Document the applicable test plan and responsible systems. Where required, check for unauthorized wireless access at least quarterly; run authenticated internal vulnerability scans at least quarterly and after significant changes; and obtain external scans from a PCI Approved Scanning Vendor at least quarterly and after significant changes as required. Resolve findings and obtain required passing rescans.
• Where in scope, perform internal and external penetration tests at least annually and after significant changes using qualified, organizationally independent testers. Test any segmentation relied on for scope reduction at least annually and after changes, and remediate and retest weaknesses.
• Where required, maintain intrusion detection/prevention and critical-file change detection, review critical-file changes at least weekly, and respond to alerts. For applicable payment pages, detect unauthorized changes to browser-received page content and headers at least every seven days or the supported risk-analysis frequency.
• Record the basis for the current questionnaire’s testing and script-attack eligibility requirements. Do not mark a scan or test complete because a policy exists or HTTPS works. Provider evidence must cover the specific systems and responsibilities used by AIOR Threads.

Keep privately: Scope and scan reports, remediation/retests, penetration tests, monitoring records.

12. Governance, providers, training, and incident response

PCI DSS 12.1–12.10 · Responsible: Dashawn White, business owner

• The owner is accountable for information security, task assignment, and truthful assessment responses. Disseminate this policy to relevant personnel and providers and obtain personnel acknowledgment. Review it at least every twelve months and after material changes. Conduct appropriate personnel screening where lawful and applicable.
• Maintain a system and data-flow inventory and confirm PCI scope at least annually and after significant changes, including channels, stored data searches, connected systems, providers, and segmentation. Determine the applicable assessment with the acquiring/compliance entity; do not assume that an online-only questionnaire covers in-person payments.
• For each control allowing a risk-based frequency, document assets, threats, likelihood, impact, chosen frequency, justification, approval, and annual reassessment. Review encryption protocols and supported technologies annually. Do not use a risk analysis to waive a fixed requirement.
• Provide security awareness at onboarding and at least annually, including phishing, social engineering, payment handling, device safety, and incident reporting. Limit acceptable technology use to authorized business purposes and record owner approval for exceptions.
• Keep a provider inventory, perform due diligence, maintain written agreements acknowledging relevant security responsibilities, and maintain a responsibility matrix. Obtain and review current compliance evidence at least annually for applicable services. Clover and PayPal processing responsibilities are separate from hosting, domain, email, and merchant responsibilities. Unverified evidence remains an open action.
• Maintain an incident response plan, verified provider/acquirer and emergency contacts, and an owner or designated responder available at all times for urgent incidents. Train responders, test the plan at least annually, and update it after tests or incidents. Service-provider-only duties and additional PCI appendices must be evaluated if business activities or designated status make them applicable.

Keep privately: Policy adoption, scope/risk reviews, training, provider agreements/AOCs, incident exercise.

Incident response procedure

1. Report and record: Notify the owner immediately. Record the time, affected service or device, observed symptoms, and available alerts. Use verified account-support contacts; do not send credentials or card data.
2. Contain: Stop affected checkout activity, isolate suspect devices or access, and involve the payment provider/acquirer. Preserve relevant logs and evidence; do not erase devices or make destructive changes without coordinated guidance.
3. Investigate: Arrange qualified support, identify unauthorized access or stored card data, determine affected records, and follow provider, payment-brand, and applicable notification obligations. Keep legal and forensic advice where needed.
4. Recover: Address the root cause, replace compromised credentials, validate the corrected environment, and restore activity only after the owner and relevant provider authorize recovery.
5. Improve: Keep a private incident report, track corrective actions, update the plan and policy, and brief relevant personnel. Test the plan annually using a scenario such as a lost phone or unauthorized checkout redirect.

The owner must maintain actual verified escalation contacts outside this public page. Report security concerns to aior23@aior.info; never include card numbers, passwords, or private tokens.

Implementation checklist

Print or save this page and record dates, evidence locations, exceptions, and actions privately. No item is pre-marked complete.

1. Record the acquiring entity’s assigned questionnaire and payment channels; do not guess eligibility.
2. Inventory actual phones, accounts, applications, payment flows, networks, and providers; identify an owner for each control.
3. Verify passcodes, device updates, MFA, unique logins, restricted administrator access, and protected recovery information.
4. Check that card entry stays inside the intended provider interfaces and that no full card data or secrets appear in business records, code, or logs.
5. Complete a private retention schedule, provider responsibility matrix, current compliance-evidence file, and verified incident contact list.
6. Confirm required logging, security testing, script protections, scans, remediation, and provider-managed evidence for the assigned assessment.
7. Review and acknowledge the policy; brief anyone with access, test incident response, and record completion dates and evidence privately.
8. Compare every applicable questionnaire clause with implemented controls and evidence. Resolve gaps before attesting that they are in place.

Clause-by-clause review worksheet

Use one row for every applicable clause in the assigned questionnaire. Repeat the worksheet as needed; twelve area headings alone are not proof that every clause is satisfied.

Official reference and review limits

Baseline: PCI SSC Document Library — PCI DSS v4.0.1 and current questionnaires. For example, current SAQ A reporting differs from the full standard; use the version assigned by the acquiring entity. This policy does not establish questionnaire eligibility, verify hosting compliance, or replace applicable assessment and testing.