Security & Compliance

01Our approach

Security and privacy are part of how we design, build and run systems — not a final checklist. We follow three ideas throughout: collect only what is needed, give access only to those who need it, and assume any single control can fail.

This page describes our practices in general terms. It is not a certification, audit report or contract. Specific commitments for a client engagement are set out in that engagement’s written agreement.

02Encryption

• In transit: websites, forms and APIs use TLS (HTTPS), with HTTP Strict Transport Security on our own site. Partner deliveries and webhooks use HTTPS endpoints.
• At rest: sensitive records — such as lead and contact-form submissions — are encrypted at the application layer with AES-256-GCM before they are written to storage.
• Key management: encryption keys and secrets live in environment configuration or restricted key files, never in source code or version control.
• Hashing: where we only need to recognize a value — such as an IP address for rate limiting — we store a keyed hash instead of the value itself.

03Infrastructure hardening

• Linux servers with minimal installed services, regular security updates and host firewalls.
• SSH key authentication for administration; password logins disabled where we control the server.
• Applications run behind a reverse proxy, with automatic TLS certificate renewal.
• Separate environments for development, staging and production.
• Security headers on our web applications, such as content-type, framing and referrer protections.
• Backups protected and restore procedures tested.

04Application security

• Input validation on every form and API, on both client and server.
• Parameterized database queries.
• Rate limiting, honeypots and origin checks on public endpoints.
• Dependency updates and vulnerability monitoring for the libraries we use.
• Code review before changes reach production.
• Personal information kept out of URLs, analytics events and application logs wherever possible.

05Access control

• Least privilege: people and services get only the access their role needs.
• Individual accounts — no shared logins — with multi-factor authentication wherever the service supports it.
• Access removed promptly when a role changes or ends, and reviewed periodically.
• Administrative actions on production systems are logged.

06Logging and monitoring

• Automated uptime, error and resource monitoring runs 24/7, with alerts to the team.
• Security-relevant events are logged and kept for up to 12 months.
• Unusual activity — such as traffic spikes, failed logins or delivery errors — triggers investigation.

07Privacy engineering

• Data minimization: forms ask only for what the request needs.
• Consent records with text version, timestamp, IP and user agent where consent is required.
• Global Privacy Control and opt-out signals honored and passed to downstream systems.
• Suppression lists checked before outreach or delivery.
• Defined retention periods, described in our Privacy Policy and Data Collection & Use Policy.

08Vendor management

• We review a vendor’s security and privacy practices before sharing data with it.
• Vendors that handle personal information are bound by confidentiality and data-protection terms.
• We share the minimum data each vendor needs, and review vendors when our use of them changes.

09Incident response

We follow a documented incident-response process:

1. Detect and triage — confirm what happened and how serious it is.
2. Contain — limit the impact, for example by revoking credentials or isolating systems.
3. Investigate and fix — find the root cause and remediate it.
4. Notify — inform affected clients, individuals and authorities without undue delay, as required by law and our agreements.
5. Learn — review the incident and improve our controls.

10Business continuity

Backups, documented runbooks and infrastructure that can be rebuilt from configuration help us recover quickly from failures. Where a client needs higher availability, we design redundancy into that engagement.

11People

Everyone who works with client or campaign data is bound by confidentiality obligations, works on a need-to-know basis and follows our security and data-handling rules.

12Laws and rules we design for

We design our systems and processes with these requirements in mind, as they apply to each engagement:

• Telephone Consumer Protection Act (TCPA), Telemarketing Sales Rule and state telemarketing laws;
• CAN-SPAM Act for commercial email;
• E-SIGN Act for electronic records and signatures;
• CCPA/CPRA and other US state privacy laws, including Global Privacy Control;
• GDPR and UK GDPR where they apply;
• advertising-platform policies.

This is a description of our approach, not legal advice or a certification of compliance. We do not claim third-party certifications on this page.

13Report a security issue

If you believe you’ve found a vulnerability in our website or systems, email hello@adonmedia.group with the subject “Security report”. Please include steps to reproduce the issue.

• Don’t access, change or delete data that isn’t yours.
• Don’t run denial-of-service, spam or social-engineering tests.
• Give us reasonable time to fix the issue before sharing it publicly.

We appreciate responsible disclosure and will work with you in good faith.

14Contact

For security or compliance questions, including vendor questionnaires, contact:

Adon Media Group Inc
Email: hello@adonmedia.group
Phone: +91 9194135536