Information Security Policy

This policy applies to PPC Nest LLC ("PPC Nest", "we"), all staff and contractors, and every system we use to store or process client data, including our internal analytics dashboard, hosting, database and source code repositories.

• Security Lead: Founder & CEO (Syed Rohail Shah). Owns this policy, the risk assessment and the incident response plan, and is the point of contact for security matters.
• Deputy Security Lead: a senior team member appointed by the Security Lead, who acts when the Security Lead is unavailable.
• All staff and contractors: must follow this policy and report suspected incidents immediately.

Security contact: rohail@ppcnest.co.

With each client's explicit authorization, we access that client's own business data: advertising performance, sales and traffic reports, search query performance, order and inventory reports, and product catalog details. We use it only to analyze and report on that client's own business.

We do not request, access or store buyer personally identifiable information (such as buyer names, addresses or contact details). We do not sell client data or share it with third parties other than the infrastructure providers listed in section 12.

• Access is granted on a least-privilege basis according to job duties. Our dashboard uses role-based access (admin, manager, viewer), and only admins can invite users or change roles.
• Accounts are invite-only. Public sign-up is disabled.
• Access is removed on the day a staff member or contractor leaves, and all access is reviewed at least every quarter.
• Passwords must be at least 12 characters and include special characters. Passwords are changed at least every 365 days, and immediately if compromise is suspected.
• Multi-factor authentication (MFA) is required on every system that holds client data or credentials, including hosting, database, source code, email and marketplace accounts.

• Application secrets, API credentials and keys are stored only in encrypted environment configuration of our hosting provider. They are never committed to source code repositories, hard-coded into applications, or shared over email or chat.
• Client authorization tokens are encrypted at rest in our database (AES-256-GCM) and are only decrypted in server-side processes at the moment they are used.
• API client secrets are rotated at least every 180 days, and immediately if exposure is suspected.

All data in transit is encrypted with TLS (HTTPS), including traffic between users and our dashboard, and between our systems, our database and marketplace APIs. Data at rest is encrypted by our hosting and database providers.

• Our applications run on managed cloud infrastructure that provides firewalls, DDoS protection, network isolation and automatic security patching.
• Staff devices used to access client data must have anti-malware protection and a firewall enabled, receive operating system security updates, and be protected by a screen lock.
• Client data must not be stored on removable media or personal devices outside approved systems.

The Security Lead carries out a documented risk assessment at least once a year and whenever there is a significant change to our systems, data use or organization. The assessment:

• lists the systems and data in scope, and who has access;
• identifies threats and weaknesses (for example credential exposure, unauthorized access, vendor outages and data loss);
• rates each risk by likelihood and impact;
• records the action taken to reduce each risk, its owner and its due date.

Results are kept in a risk register, and open actions are reviewed at every policy review.

• Our systems log data synchronization jobs, API errors and authentication events.
• Failed authorizations and repeated API errors raise alerts to the Security Lead by email.
• Alerts and logs are reviewed promptly, and any activity that may indicate unauthorized access or data exposure is treated as a potential incident under section 9.

A security incident is any event that may have led to unauthorized access to, or loss, disclosure or alteration of, client data or credentials. We respond as follows:

1. Report. Anyone who suspects an incident reports it to the Security Lead (or Deputy) immediately.
2. Assess. The Security Lead confirms whether an incident occurred, which data and clients are affected, and its severity.
3. Contain. We stop further exposure: revoke or rotate affected credentials and tokens, disable affected accounts or integrations, and preserve logs as evidence.
4. Notify. For any incident involving information received from Amazon, we notify Amazon at security@amazon.com within 24 hours of detection. Affected clients are notified without undue delay, and regulators where the law requires it.
5. Recover. We remove the cause, restore affected systems and confirm they are secure before resuming normal operation.
6. Review. Within 14 days we complete a written post-incident review covering the cause, impact and actions to prevent a repeat, and update the risk register.

This plan is reviewed, and its roles and contacts confirmed, at least every 6 months, and after every incident.

We notify Amazon, and any other data provider whose terms require it, within 30 days of any organizational change or event that affects our need for or use of their information. This includes changes of ownership or control, legal entity, business model, the services we offer, or the data we access. Notifications to Amazon are made through the Solution Provider Portal contact form.

We keep client data only for as long as the client's authorization and our engagement are active and the data is needed to provide our services. When a client revokes authorization or our engagement ends, we stop collecting their data immediately and delete it within 30 days, unless the client asks us in writing to keep it or the law requires us to retain it.

We use a small number of infrastructure providers that act as data processors under their own security and data protection terms: Vercel (application hosting) and Supabase (database). We review their security practices before use and at each policy review.

All staff and contractors with access to client data read and acknowledge this policy when they join and after each revision. The Security Lead reviews this policy at least every 6 months and whenever our systems or data use change significantly.

See also our Privacy Policy and Terms of Service.