Information Security Policy

1. Purpose & Scope

This Information Security Policy (“Policy”) establishes DataChimp Labs’ program for identifying, mitigating, and monitoring information security risks that are relevant to our business, our products, and the data we process on behalf of our customers.

The Policy applies to:

All DataChimp Labs personnel — employees, contractors, and interns.
All information systems, networks, applications, and cloud environments owned, leased, or operated by DataChimp Labs.
All data processed, stored, or transmitted by DataChimp Labs systems, including customer data, personally identifiable information (PII), protected health information (PHI), and export-controlled technical data.
All third parties that access DataChimp Labs systems or data under a written agreement.

2. Vendor Questionnaire Response — Documented and Operationalized Program

Q. Does your organization have a documented information security policy and procedures that have been operationalized to identify, mitigate, and monitor information security risks relevant to your business?

A. Yes. DataChimp Labs maintains a documented information security policy, supporting procedures, and an operational information security program that is continuously matured.

Evidence:

Documented policy. This Information Security Policy is the master document. It is complemented by topic-specific policies covering access control, authentication and multi-factor authentication, encryption at rest, encryption in transit, vulnerability management, data retention and disposal, and privacy — all published in the public Trust Center at https://trust.datachimplabs.com/.
Documented procedures. Operational runbooks, standards, and procedures backing every control in this Policy are maintained in the corporate documentation repository and are available on request under NDA through security@datachimplabs.com.
Operationalized program. Controls are enforced continuously through cloud-native infrastructure-as-code, CI/CD security gates, centralized logging and monitoring, automated vulnerability scanning, and quarterly human review cycles (access reviews, risk assessments, tabletop exercises).
Continuous maturation. The program improves through incident post-mortems, internal audits, external third-party assessments (including penetration tests), industry-benchmark control gap analysis, and a structured annual policy review — see §15 (Policy Review Cadence) and §14 (Compliance and Audit).

Detailed mappings:

Identify — see §6 (Risk Management Program) and §7 (Security Controls).
Mitigate — see §7 (Security Controls), §8 (Access Control and Identity Management), and §9 (Data Classification and Handling).
Monitor — see §10 (Incident Response) and §14 (Compliance and Audit).
Govern — see §5 (Governance and Ownership).

3. Regulatory Compliance Obligations

Q. Please describe your regulatory compliance obligations and how you comply with them.

DataChimp Labs is a SaaS platform serving customers in healthcare, financial services, and regulated commercial verticals. Our regulatory obligations fall into the following categories, each mapped to a control set we operationalize continuously.

3.1 HIPAA Security and Privacy Rules (as a Business Associate)

Where we process protected health information (PHI) on behalf of covered-entity customers, DataChimp Labs acts as a Business Associate as defined under 45 CFR §160.103. We execute a Business Associate Agreement (BAA) with the customer before any PHI is exchanged, and we flow-down equivalent BAA terms to any subprocessor that will access PHI.

We implement the administrative, physical, and technical safeguards required by the HIPAA Security Rule (45 CFR §§164.308–164.316), including:

Access controls with unique user identification, automatic logoff, and emergency access procedures (§164.312(a)).
Audit controls capturing access, modification, and administrative actions on ePHI (§164.312(b)); security event logs retained for a minimum of six years (§164.316(b)(2)).
Encryption of ePHI at rest (AWS KMS-managed keys) and in transit (TLS 1.2+), per our Encryption at Rest and Encryption in Transit Policies (§164.312(a)(2)(iv) and §164.312(e)(2)(ii)).
Workforce training and sanction policies (§164.308(a)(3) and (a)(5)).
Incident response and breach notification procedures aligned with the HIPAA Breach Notification Rule (45 CFR Part 164 Subpart D).
Secure disposal of ePHI following the Data Retention and Disposal Policy (§164.310(d)(2)).

For personal data originating in the European Union, European Economic Area, or United Kingdom, DataChimp Labs acts as a Processor under GDPR Article 28 and the UK GDPR equivalent. We enter into a Data Processing Addendum (DPA) with customers, honor data subject rights (access, rectification, erasure, portability, restriction, objection) within statutory timeframes, apply data-minimization and storage- limitation principles under our Data Retention and Disposal Policy, and use Standard Contractual Clauses (SCCs) — with supplementary measures where required by Schrems II — as the transfer mechanism for lawful cross-border transfers.

3.3 CCPA and CPRA (California)

We honor California consumer rights to know, delete, correct, and limit use of sensitive personal information under Cal. Civ. Code §§1798.100 et seq. We disclose our retention periods in the Data Retention and Disposal Policy, and we do not sell or share personal information for cross- context behavioral advertising as defined under California law.

3.4 SOC 2 (Trust Services Criteria)

DataChimp Labs is actively preparing for a SOC 2 Type II examination against the AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, and Privacy). Our internal control framework and evidence collection are structured to satisfy the TSC. See §14 (Compliance and Audit) for our current audit posture.

3.5 Financial-services retention (AML, tax, audit)

For customers whose data flows include transactional or financial-account information (e.g., aggregated financial account data via Plaid), we retain and dispose of records to satisfy the more protective of applicable anti-money-laundering, tax, and audit statutory minimums — typically five (5) to seven (7) years for transaction records — while honoring earlier deletion requests where lawfully permitted. See the Data Retention and Disposal Policy §4.

3.6 Export controls (ITAR / EAR) — architectural readiness

DataChimp Labs is architected to segregate export-controlled technical data (ITAR / EAR) in dedicated environments with U.S.-persons- only access and controlled destruction procedures at end of life. Where a customer engagement requires handling of export-controlled data, we formalize the applicable controls in the customer agreement and confirm subprocessor eligibility before onboarding.

3.7 Cross-cutting operational controls

Compliance with the above regimes is operationalized through the same underlying program:

A documented and continuously matured information security program aligned with ISO/IEC 27001 and the NIST Cybersecurity Framework (§2 and §4).
Cloud-native infrastructure with least-privilege IAM, MFA-required access, encryption at rest (AWS KMS) and in transit (TLS 1.2+), and centralized logging with security-relevant events retained for a minimum of six years.
Automated vulnerability scanning and prioritized remediation per the Vulnerability Management Policy.
Quarterly access reviews, annual policy reviews, annual risk assessments, tabletop exercises, and third-party penetration testing.
Vendor risk management — subprocessors are reviewed prior to onboarding and re-evaluated annually (§12).
Employee security training on hire and annually thereafter (§13).

Additional evidence — including SOC 2 audit status, most recent penetration-test attestation, and the current subprocessor list — is available under NDA through security@datachimplabs.com.

4. Policy Statement

DataChimp Labs maintains a documented, operationalized information security program aligned with the ISO/IEC 27001 control family, the NIST Cybersecurity Framework, and — where applicable — the HIPAA Security Rule, SOC 2 Trust Services Criteria, ITAR handling requirements, and DoD Impact Level (IL) baselines.

The program is:

Documented in this Policy and supporting standards, procedures, and runbooks maintained in the corporate documentation repository.
Operationalized through automated controls in our cloud infrastructure, CI/CD pipelines, and monitoring systems, and through recurring human processes (access reviews, risk assessments, tabletop exercises).
Continuously improved through incident post-mortems, internal audits, external assessments, and structured change management.

5. Governance & Ownership

Security governance at DataChimp Labs is a shared responsibility with clearly assigned accountability:

Role	Responsibility
Chief Technology Officer	Executive owner of the security program; approves policy; allocates resources; reports risk to leadership.
Security Lead	Day-to-day owner of the security program; maintains policies, controls, risk register, and incident response.
Engineering Leadership	Implements technical controls; owns SDLC security; owns cloud architecture and infrastructure hardening.
Compliance Lead	Owns audit readiness, framework mappings (SOC 2, HIPAA, GDPR, ITAR, IL6), and vendor security reviews.
Data Protection Officer	Owns privacy program, data subject rights, and cross-border transfer compliance where required by law.
All Personnel	Follow this Policy; complete required training; report suspected incidents without delay.

A Security Steering group composed of the roles above meets at least quarterly to review the risk register, open findings, and program metrics.

6. Risk Management Program

DataChimp Labs operates a continuous risk management program consisting of four phases: identify, assess, mitigate, monitor.

4.1 Risk Identification

Asset inventory — automated discovery of cloud resources across all AWS accounts (compute, storage, databases, secrets, network) is refreshed continuously and reconciled against source-of-truth infrastructure-as-code.
Threat modeling — every new service or material architectural change is threat-modeled during design review using STRIDE, and the outputs are linked to the risk register.
Continuous scanning — dependency scanning (SCA), static analysis (SAST), container image scanning, and cloud configuration scanning run on every pipeline execution and on a scheduled basis against production.
External signals — CVE feeds, vendor security advisories, and threat intelligence relevant to our technology stack are monitored and triaged.

4.2 Risk Assessment

A formal enterprise risk assessment is performed at least annually and whenever there is a material change (new product line, significant architectural change, new regulatory obligation, merger/acquisition, material incident).
Risks are scored on likelihood and impact (1–5 each) and combined into an inherent risk rating; residual risk is calculated after applying compensating controls.
Results are captured in the risk register and reviewed by the Security Steering group.

4.3 Risk Mitigation

Controls are selected based on the residual risk rating and the classification of the affected data. Remediation service-level objectives:

Severity	Example	Remediation SLA
Critical	Actively exploited vulnerability; confirmed data risk	24 hours to mitigation
High	Exploitable vulnerability in production; missing MFA	7 calendar days
Medium	Hardening gap; expired evidence	30 calendar days
Low	Documentation or cosmetic finding	90 calendar days

Note: this table governs remediation of assessed risks. Patch-specific SLAs for identified vulnerabilities are defined in the Vulnerability Management Policy §5 and measure a distinct control.

Exceptions require a documented risk acceptance signed by the Security Lead and, for critical/high items, the CTO, with a defined expiration date.

4.4 Risk Monitoring

Centralized logging — application, infrastructure, network, and identity logs are aggregated to an immutable log store with access-controlled retention aligned to regulatory minimums.
Detection & alerting — high-signal detections (privilege escalation, anomalous data egress, unauthorized configuration changes, failed authentication spikes) generate alerts routed to on-call engineers.
Quarterly reviews — the risk register, open findings, control test results, and metrics (mean time to detect, mean time to remediate, control coverage) are reviewed by the Security Steering group at least quarterly.

7. Security Controls

DataChimp Labs implements defense-in-depth across its cloud-native platform:

Cloud & Network

Multi-account isolation — production workloads run in dedicated AWS sub-accounts under an AWS Organization, providing hard blast-radius boundaries between tenants, environments, and business units.
Private VPCs — application workloads run in private subnets; ingress is limited to load balancers with WAF; egress is controlled via NAT and allow-lists where required.
Encryption in transit — TLS 1.2+ is required on all external endpoints and internal service-to-service communication.
Encryption at rest — all persistent stores (S3, RDS, DynamoDB, EBS, Secrets Manager, SSM Parameter Store SecureString) are encrypted with AWS KMS-managed keys; customer-managed keys are used where required by contract or regulation.

Identity & Access

Least privilege — IAM roles are scoped per-service; standing human access to production is prohibited by default. Break-glass procedures are documented and audited.
MFA — multi-factor authentication is enforced for all human access to identity providers, source control, cloud consoles, and administrative interfaces.
Federation — human access is federated through a single identity provider; local accounts on individual systems are prohibited except for documented break-glass use.
Access reviews — access to production systems, source control, and sensitive data stores is reviewed at least quarterly.

Application & CI/CD

Signed, reviewed changes — production changes flow through pull requests requiring code review; production deployments require an approval gate; deployments are performed by automation, not humans.
Reproducible builds — infrastructure-as-code and versioned pipelines make production state auditable and reproducible.
Secrets management — application secrets are stored in AWS Secrets Manager or SSM Parameter Store (SecureString) and injected at runtime; no secrets in source control.
SDLC security gates — SAST, SCA, secret scanning, and container image scanning run on every pipeline; failures block merges and deployments.

Endpoint & Workforce

Workforce endpoints are centrally managed with full-disk encryption, screen lock, automatic patching, and endpoint protection.
Removable media use is restricted; personal devices accessing DataChimp Labs data must meet baseline security requirements.

8. Access Control & Identity Management

All access follows the principles of least privilege and need-to-know.
Roles and entitlements are defined in infrastructure-as-code where possible and reviewed for excess privilege on each change.
Onboarding and offboarding follow documented procedures. Access is provisioned when the business justification is approved and revoked within one business day of role change or termination.
Privileged access (production administrator, root, IAM administrator) is strictly limited, logged, and reviewed monthly.

9. Data Classification & Handling

DataChimp Labs classifies data into four tiers. Each tier carries handling requirements for storage, transmission, access, and retention:

Tier	Examples	Handling
Public	Marketing content, published documentation	Standard controls; may be published externally.
Internal	Internal engineering docs, non-sensitive business records	Access limited to personnel; not published without review.
Confidential	Customer PII, financial data, credentials, business-sensitive data	Encrypted at rest and in transit; access role-restricted; access logged; retention enforced.
Restricted	PHI, payment card data, ITAR-controlled technical data, secrets	Confidential controls plus segregation, enhanced logging, DLP where applicable, and regulatory handling requirements (HIPAA, PCI, ITAR).

PHI is handled in accordance with the HIPAA Security Rule and Business Associate Agreements executed with covered entities and other business associates. ITAR-controlled technical data is only processed in US-person-only environments with export-controlled access enforced. Data tiers and their controls are reviewed as part of every design review.

10. Incident Response

DataChimp Labs maintains an Incident Response Plan aligned to the NIST SP 800-61 lifecycle:

Prepare — playbooks, on-call rotations, communication channels, and tabletop exercises are maintained.
Detect — alerts from logging, monitoring, endpoint protection, and external reports are triaged 24/7 by on-call engineers.
Contain — confirmed incidents are contained through credential rotation, network isolation, IAM revocation, and/or workload quarantine.
Eradicate — root cause is identified and the underlying vulnerability or misconfiguration is remediated.
Recover — affected systems are restored from known-good state and monitored for recurrence.
Post-mortem — every material incident produces a blameless post-mortem with corrective actions tracked to closure.

Notification. Customer notification obligations are contractually and regulatorily driven. For personal data breaches subject to GDPR, DataChimp Labs notifies the relevant supervisory authority within 72 hours of awareness where required. For HIPAA-covered PHI incidents, DataChimp Labs notifies affected covered entities without unreasonable delay and no later than 60 days from discovery, as required by 45 CFR § 164.410. Customer notification SLAs specified in Master Services Agreements take precedence where stricter.

11. Business Continuity & Disaster Recovery

Backups — all persistent data stores are backed up with point-in-time recovery or scheduled snapshots; backups are encrypted and periodically tested for restorability.
Multi-AZ — production workloads are deployed across multiple AWS Availability Zones by default.
Recovery objectives — RTO and RPO targets are defined per-service based on business criticality, and DR tests are performed at least annually.
Business continuity plan — the BCP covers personnel unavailability, cloud provider disruption, vendor failure, and physical events; it is reviewed at least annually.

12. Vendor / Third-Party Risk Management

Vendors that process DataChimp Labs or customer data are reviewed prior to engagement. Reviews consider SOC 2 / ISO 27001 attestations, data processing terms, sub-processor lists, and residency.
Data Processing Addenda (DPAs) and, where PHI is involved, Business Associate Agreements (BAAs) are executed with all in-scope vendors.
Critical vendors are re-reviewed annually or on material change.

13. Training & Awareness

All personnel complete security and privacy awareness training upon onboarding and at least annually thereafter.
Role-based training is provided for engineers (secure development), operators (production access), and personnel with access to PHI, ITAR, or other regulated data.
Phishing simulations and targeted awareness campaigns are conducted periodically.

14. Compliance & Audit

Internal audit — an internal review of policy adherence and control effectiveness is performed at least annually.
External audits — DataChimp Labs is preparing for SOC 2 Type II attestation. The observation window and audit firm will be published in this section once contracted; interim controls in this repository apply today. DataChimp Labs also maintains ongoing alignment with the HIPAA Security Rule. Additional frameworks (GDPR, ITAR, IL6) are addressed on a workload basis where contractually or legally required.
Findings — audit findings are tracked in the corrective action register with owners and due dates, and closed with documented evidence.

15. Policy Review Cadence

This Policy is reviewed by the Security Lead and approved by the CTO at least annually and additionally whenever there is a material change to the platform, product, regulatory landscape, or organization. The next scheduled review date is recorded in the front-matter of this document.

16. Enforcement

Compliance with this Policy is a condition of employment or engagement with DataChimp Labs. Violations may result in disciplinary action up to and including termination of employment or contract, and, where appropriate, referral to law enforcement.

17. Approval & Version History

Version	Date	Author	Change
1.0	2026-09-01	DataChimp Labs — Security	Initial issue of the Information Security Policy.

Approved by: CTO, DataChimp Labs (signature on file with the Security Lead).

Contact. Security questions, disclosures, and audit inquiries related to this Policy should be directed to security@datachimplabs.com. Postal correspondence: DataChimp Labs, 4507 N 189th St, Elkhorn, NE 68022, USA.