Security Addendum
The technical and organizational measures we maintain to protect your data. We will not materially weaken them during the term.
Incorporated by reference into the Master Subscription Agreement at MSA §6.7 and DPA §3.5.
NECESSITYWORKS, INC. — SECURITY ADDENDUM
Version: 1.0 Published at: https://necessityworks.com/legal/security-addendum Applies to: NecessityWorks, Inc. (Delaware) Describes: NW’s technical and organizational measures (TOMs) for the NW security platform
1. Scope
This Security Addendum describes the administrative, physical, and technical safeguards (“Technical and Organizational Measures” or “TOMs”) that NW implements to protect Customer Data, including Customer Personal Data, against unauthorized access, disclosure, alteration, or destruction.
2. Information Security Program
2.1 Security Program. NW maintains a comprehensive Information Security Program (“ISP”) aligned to the ISO/IEC 27001 framework and the NIST Cybersecurity Framework. The ISP is documented, reviewed at least annually, and approved by NW executive leadership.
2.2 Governance.
- NW has appointed a senior executive responsible for information security (CISO or equivalent role).
- The CISO reports to the CEO and is authorized to direct the security program, investigate incidents, and require remediation.
- A cross-functional security committee meets at least quarterly to review the security program, incidents, risks, and roadmap.
2.3 Policies and Procedures. NW maintains written information-security policies covering, at a minimum:
- Information classification and handling
- Access control
- Identity and authentication
- Encryption and key management
- Network security
- Vulnerability management
- Secure software development
- Change management
- Incident response
- Business continuity and disaster recovery
- Third-party risk management
- Acceptable use for NW personnel
- Data-handling for Personal Data and PHI
- AI/ML governance
Policies are reviewed at least annually and updated as needed. Material revisions are communicated to personnel.
2.4 Risk Assessments. NW conducts formal risk assessments at least annually and on material changes to the Platform, Subprocessors, or threat landscape. Risk findings are tracked to closure with assigned owners.
3. Personnel Security
3.1 Background Checks. NW conducts pre-employment background checks on all employees and contractors with access to Customer Data, to the extent permitted by applicable law, including criminal-history and employment-history verification.
3.2 Confidentiality and IP Assignment. All NW personnel and contractors with access to Customer Data execute confidentiality agreements and proprietary-information / invention-assignment agreements before access is granted.
3.3 Security Training. NW personnel complete: - Security-awareness training at onboarding and at least annually thereafter, covering phishing, social engineering, password hygiene, data handling, and incident reporting. - Role-based training for personnel whose roles warrant it (e.g., secure coding for engineers, privacy for data handlers, incident response for on-call engineers).
3.4 Phishing Simulations. NW conducts internal phishing simulations at least quarterly.
3.5 Access Termination. On separation of any NW personnel (voluntary or involuntary), access to production systems and Customer Data is revoked within one (1) business hour of the separation decision.
3.6 Disciplinary Process. NW maintains a documented process for addressing security-policy violations, including formal disciplinary action up to and including termination of employment.
4. Access Control
4.1 Principle of Least Privilege. Access to production systems and Customer Data is granted on the least-privilege / need-to-know basis and is explicitly approved.
4.2 Multi-Factor Authentication. MFA is required for all access to production systems by NW personnel, regardless of network location.
4.3 Privileged Access Management. Privileged production access is: - Granted through a just-in-time workflow with management approval; - Subject to session-level audit logging; - Time-bounded (sessions expire within a defined window); and - Reviewed at least quarterly.
4.4 Access Reviews. Access rights to production systems and Customer Data are formally reviewed at least quarterly. Stale access is revoked.
4.5 Customer Tenant Isolation. Customer Data is logically isolated per tenant using platform-level access controls. NW does not share Customer Data across tenants. AI artifacts (embeddings, fine-tunes, memory) are tenant-scoped per MSA §6.3 and AI Services Supplement §4.2.
5. Data Protection
5.1 Encryption in Transit. All Customer Data transmitted over public networks between Customer systems and the Platform is encrypted using TLS 1.2 or higher, with strong cipher suites. Internal service-to-service traffic within NW’s infrastructure is encrypted in transit using mutual TLS or equivalent controls.
5.2 Encryption at Rest. Customer Data is encrypted at rest using AES-256 (or equivalent NIST-approved algorithms). Database storage, object storage, and backups are encrypted at rest.
5.3 Key Management. Cryptographic keys are managed using AWS Key Management Service (KMS) with customer-grade key-rotation policies. Keys are rotated on a documented schedule; access to key material is restricted and audited.
5.4 Tenant Key Isolation. At v1, encryption keys are NW-managed via AWS KMS, with per-tenant data segregation enforced at the application and database layer. Customer-Managed Keys (CMK / BYOK) are on NW’s roadmap and may be made available as an Enterprise-tier add-on; until generally available, Customers requiring CMK should flag the requirement at Order Form execution so NW can evaluate feasibility case-by-case.
5.5 Data Minimization. NW collects and processes only the Customer Data necessary to provide the Services.
5.6 Data Segregation. Production Customer Data is segregated from non-production environments (development, staging, test). Development and test environments do not contain real Customer Data except where expressly authorized and de-identified.
6. Network Security
6.1 Infrastructure. The Platform is hosted on AWS. NW relies on AWS’s underlying infrastructure security controls (see §10) and layers additional controls in its own VPCs.
6.2 Network Segmentation. Production, staging, development, and corporate networks are segregated. Access between segments is permitted only through controlled, auditable paths.
6.3 Perimeter Controls. Internet-facing services are protected by: - Web application firewalls (WAF) with threat-intelligence feeds - DDoS mitigation via AWS Shield - Rate limiting and abuse-protection controls - TLS termination at hardened load balancers
6.4 Intrusion Detection. NW operates intrusion-detection and anomaly-detection controls and reviews alerts on a 24/7 basis.
6.5 Remote Access. NW personnel access production systems only via approved, MFA-protected access paths. No direct public internet access to production databases or compute resources is permitted.
7. Application Security
7.1 Secure Software Development Lifecycle (SSDLC). NW’s SDLC incorporates security at each stage:
- Design review for material features, including threat modeling for sensitive capabilities (STRIDE/DREAD);
- Secure-coding standards documented and enforced;
- Code review of all production changes by at least one qualified reviewer other than the author;
- Static application security testing (SAST) on every merge;
- Software composition analysis (SCA) to identify vulnerable dependencies;
- Dynamic application security testing (DAST) on staging environments on a regular cadence;
- Secrets detection to prevent credentials and keys from being committed to source.
7.2 Penetration Testing. NW engages independent, qualified third-party testers to conduct penetration tests of the Platform at least annually. Test scope covers the production Platform, customer-facing APIs, and authentication flows. NW remediates findings based on severity, and a summary of the most recent test is available to Customer under NDA on request.
7.3 Vulnerability Disclosure Program. NW operates a responsible vulnerability disclosure program at https://necessityworks.com/.well-known/security.txt and recognizes good-faith security research.
8. Vulnerability and Patch Management
8.1 Scanning. NW conducts regular vulnerability scanning of production infrastructure and container images.
8.2 Severity-Based SLAs. Vulnerabilities in the Platform are triaged by CVSS severity and remediated to the following target timeframes from discovery:
| Severity | Target Remediation |
|---|---|
| Critical (CVSS ≥ 9.0) | 7 days |
| High (CVSS 7.0–8.9) | 30 days |
| Medium (CVSS 4.0–6.9) | 90 days |
| Low (CVSS < 4.0) | 180 days |
These are targets, not hard SLAs. Where a vulnerability affects a Subprocessor, NW’s remediation obligation is limited to applying the Subprocessor-provided fix once available, plus any required compensating controls.
8.3 OS and Dependency Patching. Operating systems and critical dependencies are patched on a documented cadence consistent with §8.2.
9. Security Operations, Logging, and Monitoring
9.1 Audit Logging. NW maintains audit logs of security-relevant events, including authentication, privileged access, configuration changes, and administrative actions. Logs are stored in tamper-resistant storage.
9.2 Retention. Security audit logs are retained for at least one (1) year. Certain logs may be retained longer to meet regulatory or contractual requirements.
9.3 SIEM and Alerting. Security events are ingested into a SIEM with defined detection rules and alert thresholds. Alerts are reviewed on a 24/7 basis.
9.4 Customer Audit Logs. Customer-facing audit logs (per-tenant) are available to Customer through the Platform, with documented retention and export capabilities per the applicable Service Description.
10. Physical Security
10.1 Data Center. The Platform operates in AWS data centers. Physical security of the data centers is the responsibility of AWS and is governed by AWS’s then-current certifications (including SOC 2, ISO/IEC 27001, and related standards).
10.2 NW Offices. NW’s offices (and remote-work setups used by personnel with production access) operate under documented controls, including physical-access restrictions, device security, and clean-desk policies where applicable.
11. Incident Response
11.1 Runbook. NW maintains a documented Incident Response Plan with defined roles, escalation paths, and communication protocols.
11.2 Detection and Triage. NW operates 24/7 security monitoring. Suspected incidents are triaged by trained personnel within defined SLAs.
11.3 Customer Notification. NW will notify Customer of a confirmed Security Incident (as defined in the DPA) affecting Customer Data within forty-eight (48) hours per MSA §7.3 and DPA §8. Notification content conforms to DPA §8.2.
11.4 Post-Incident Review. NW conducts a formal post-incident review for material incidents, identifies root causes, and tracks corrective actions to closure.
11.5 Regulatory Reporting. NW cooperates with Customer, at Customer’s expense, in any required regulatory reporting or notification under applicable law.
12. Business Continuity and Disaster Recovery
12.1 BC/DR Plan. NW maintains a documented Business Continuity and Disaster Recovery plan, tested at least annually.
12.2 Targets.
- Recovery Time Objective (RTO): four (4) hours for the production Platform under a Region-localized failure scenario; longer recovery times may apply for multi-Region or full-AWS-account failures, in which case NW will use commercially reasonable efforts and provide best-available status updates
- Recovery Point Objective (RPO): one (1) hour for Customer Data stored in production-tier managed databases (Postgres point-in-time recovery via AWS RDS automated backup retention)
12.3 Backups. Customer Data is backed up on a documented schedule. Backups are encrypted, stored in geographically separated locations, and tested periodically.
12.4 Failover. The Platform is designed to tolerate single-availability-zone failure within an AWS region. Multi-region failover capability is on NW’s roadmap and documented in the applicable Service Description if offered.
13. Third-Party (Subprocessor) Security
13.1 Due Diligence. NW conducts security due diligence on Subprocessors prior to onboarding, including review of certifications (SOC 2, ISO 27001), security questionnaires, and assessment of data-handling practices.
13.2 Contractual Obligations. NW requires Subprocessors that Process Customer Personal Data to enter data-protection agreements imposing obligations at least as protective as those in this Security Addendum and the DPA.
13.3 Ongoing Monitoring. NW re-assesses Subprocessors on a documented cadence (typically annually) and monitors for material changes to their certifications or control environments.
14. Certifications and Attestations
14.1 Current.
- SOC 2 Type II: Observation window is active. NW has elected to go directly to Type II without a separate Type I engagement. A readiness/observation letter, including the current observation-window and target attestation dates, is available on request under NDA.
14.2 Roadmap.
- SOC 2 Type II: Final attestation in progress; target date available on request under NDA.
- ISO/IEC 27001: Gap assessment targeted; certification on roadmap post-SOC 2 Type II.
- HITRUST: Under evaluation pending healthcare customer commitments.
- FedRAMP: Under evaluation pending public-sector strategy.
14.3 Third-Party Attestations. On Customer’s written request and subject to reasonable confidentiality obligations, NW will make available its then-current SOC 2 Type II report (or comparable attestation) and completed standard security questionnaires.
15. Shared Responsibility Model
Security of Customer Data is a shared responsibility between NW and Customer.
| NW is responsible for… | Customer is responsible for… |
|---|---|
| Securing the underlying Platform, infrastructure, and NW-managed services | Securing Customer credentials, API keys, and Customer-controlled integrations |
| Maintaining the ISP, TOMs, and certifications described here | Configuring the Platform consistent with Customer’s compliance posture |
| Responding to and notifying Customer of Security Incidents affecting the Platform | Monitoring Customer’s use of the Platform for abnormal activity within Customer’s environment |
| Subprocessor security oversight | Security of Customer’s systems, networks, and endpoints that connect to the Platform |
| Tenant isolation at the platform layer | Role-based access provisioning within Customer’s tenant |
| Patching the Platform | Keeping client-side agents or integrations updated where Customer controls them |
16. Changes to this Addendum
NW may update this Security Addendum from time to time in accordance with MSA §18(m). Material adverse changes take effect no earlier than thirty (30) days after notice. Changes that enhance security commitments may take effect immediately.