Security

1. Governance

• A named security owner at director level, with a documented information security policy reviewed annually.
• Practices aligned to ISO/IEC 27001 and SOC 2 Trust Services Criteria; we are working towards certification and will state our status in proposals.
• Every engineer completes security and data-protection training at onboarding and annually, including AI-specific risks.
• Background verification for all staff with access to client systems or data.

2. Access control

• Single sign-on with mandatory multi-factor authentication on all company systems, code hosting, cloud consoles and client environments.
• Least-privilege, role-based access; client credentials are issued per engagement, scoped to what the work requires, and revoked at handover.
• No shared accounts. Secrets are stored in a managed secrets vault, never in code, tickets or chat.
• Access reviews at the start and end of every engagement and quarterly for standing systems.

3. Data handling

• Client project data is processed in the region you specify, in your cloud account wherever possible, so that ownership, residency and audit remain yours.
• Encryption in transit (TLS 1.2 or higher) and at rest (AES-256 or provider-managed equivalent) by default.
• Production data is not copied to laptops or personal devices. Where samples are needed for development and evaluation, we use anonymised or synthetic data under written agreement.
• Data classification in every SOW: what we may access, where it may live, how long we keep it, and how it is returned or deleted at the end. Deletion is confirmed in writing.
• Company devices are managed, full-disk encrypted, screen-locked and remotely wipeable.

4. Secure development

• All code in version control with protected main branches, peer review on every change, and no direct pushes to production.
• Automated dependency and secret scanning, static analysis and container scanning in continuous integration; critical findings block release.
• Separate development, staging and production environments; infrastructure defined as code and peer-reviewed like application code.
• OWASP Top 10 and API Security Top 10 checks are part of the definition of done; input validation, output encoding, authentication and authorisation are tested, not assumed.
• Dependencies pinned and updated on a schedule, with emergency patching for critical vulnerabilities.
• Independent penetration testing arranged before launch where the SOW or your policy requires it.

5. AI-specific controls

AI systems introduce risks that conventional software does not. We design for them explicitly:

• Prompt injection and data exfiltration: retrieved content and tool outputs are treated as untrusted; system instructions are isolated; outputs that trigger actions are validated against schemas and policy before execution.
• Least-privilege agents: every agent has a scoped tool set, permissions bounded to what the user could do themselves, spend and rate limits, and approval gates for sensitive actions. Autonomy is expanded only after evaluation evidence.
• Permission-aware retrieval: document-level access controls are enforced at query time so users only receive content they are entitled to see.
• Evaluation before release: a golden set and regression suite run on every prompt or model change; releases are blocked on regression.
• Full traceability: every model call is logged with inputs, outputs, model version, user and cost to an audit store you control.
• PII minimisation: redaction or tokenisation before data reaches a model where the use case allows; private or self-hosted models where residency or contract requires it.
• Provider terms: we use enterprise or API terms that prohibit providers from training on your data, and we document which providers touch which data in the SOW.
• Human oversight: clear hand-off paths, kill switches and monitoring dashboards for every autonomous system we ship.

6. Infrastructure and operations

• Cloud infrastructure on AWS, Google Cloud, Azure, Vercel or Hostinger as chosen with you, using provider security baselines, private networking, security groups and managed identity.
• Centralised logging, uptime and error monitoring with alerting to an on-call engineer under Care Plans.
• Automated, encrypted backups with tested restores; recovery objectives agreed per system in the SOW.
• Network access to production restricted to named engineers over MFA-protected channels; no long-lived credentials.

7. Vendor and sub-processor management

We assess the security posture of every vendor that could touch client data before use, prefer providers with recognised certifications, and maintain a list of sub-processors for each engagement that you approve in the SOW. Changes are notified in advance with a right to object.

8. Incident response

• A documented incident response plan with severity levels, roles and communication templates, exercised annually.
• Suspected incidents are triaged within one hour of detection during business hours and within four hours otherwise; Enterprise Care Plan clients receive 24×7 response.
• Affected clients are notified without undue delay and within 24 hours of confirmation, with a written post-incident report including root cause and remediation.
• Regulatory notifications are made within statutory periods where we are the responsible party, and we assist you with yours where we are processor.

9. Business continuity

Our work is distributed across Bengaluru, New York and London with redundant connectivity, so a single-location outage does not stop delivery. All work product is in version control and cloud storage with no single point of failure; laptops are replaceable in a day. Client systems we operate have documented continuity plans in their runbooks.

10. Compliance frameworks we design to

• India: Digital Personal Data Protection Act 2023, IT Act 2000 and rules, RBI guidelines on outsourcing and data localisation for BFSI clients, CERT-In directions.
• EU/UK: GDPR and UK GDPR, NIS2 where applicable to client sectors.
• USA: CCPA/CPRA, HIPAA safeguards for healthcare engagements (as a business associate where a BAA is signed), GLBA considerations for financial clients.
• Sector: PCI DSS scope minimisation (we do not store card data), education data protections including for minors, and audit-trail requirements for regulated decisions.
• AI: EU AI Act risk categorisation, NIST AI Risk Management Framework and OWASP Top 10 for LLM Applications inform our design reviews.

11. Responsible disclosure

If you believe you have found a security vulnerability in theeazyware.com or a system we operate, email security@theeazyware.com with enough detail to reproduce it. Please do not access, modify or exfiltrate data beyond what is needed to demonstrate the issue, and give us reasonable time to fix it before public disclosure. We will acknowledge within two working days, keep you informed, and credit you if you wish. We do not pursue legal action against good-faith researchers who follow this process.

12. Questions and questionnaires

Email security@theeazyware.com for our security overview, sub-processor list, penetration test summaries under NDA, or to send a vendor security questionnaire. We answer within five working days.