{"vendor":"NEDOCS","legalEntity":"I AM GRACE INC. (California corporation)","product":"NEDOCS — National Emergency Department Overcrowding Scale and surge operations platform","contact":"Attn: Compliance & Security, 2121 Avenue of the Stars, Suite 800, Century City, CA 90067","lastUpdated":"July 1, 2026","version":"2026-07-01","summary":"NEDOCS is a HIPAA business-associate-ready emergency-department operations platform operated by I AM GRACE INC. This page summarizes our current security and privacy posture for hospital IT, procurement, and reviewers. The evaluation tier operates without PHI; production use with protected health information requires a separately executed Business Associate Agreement (BAA). Detailed questionnaire answers for automated assessments are available via the JSON and CSV links below.","attestation":"Answers are maintained by I AM GRACE INC. and reflect the state of the NEDOCS service as of the version date. Application-level controls are verifiable in the product; organizational controls are supported by policy and, where noted, third-party attestation available under NDA.","domains":[{"id":"iam","section":"InfoSec","category":"Identity and Access Management","overview":"Every production sign-in requires multi-factor authentication. Accounts are protected by password policy, brute-force lockout, role-based access, hospital-scoped tenancy, and configurable session timeouts.","highlights":["Mandatory MFA at every sign-in — email one-time code by default; authenticator app (TOTP) optional","Password policy enforced on create, change, and reset: minimum 8 characters with uppercase, lowercase, and number","Account lockout after 10 consecutive failed attempts for 15 minutes (both configurable)","Role-based access control with hospital-scoped data isolation and least-privilege provisioning","30-minute idle session timeout (configurable); secure HTTP-only, SameSite session cookies in production","Server-side session store; shared and generic email accounts prohibited as primary identities"],"items":[{"id":"2289","question":"Does your product support Multi-Factor Authentication (MFA) for customer users when logging into your system?","answer":"Yes","options":["Yes","No"],"status":"Remediated","notes":"NEDOCS supports multi-factor authentication for all customer accounts, with two methods. The default method emails a 6-digit one-time code to the account email address (which is also the username); the alternative is an app-based TOTP (RFC 6238) authenticator (Google/Microsoft Authenticator, 1Password, Authy) enrolled by scanning a QR code. After a correct password the user is challenged for the code before a session is established. Email codes expire in 10 minutes and are stored only as SHA-256 hashes; TOTP secrets are encrypted at rest. MFA can additionally be mandated for privileged roles via configuration.","frameworks":["NIST CSF V1.1: PR.AC-1, PR.AC-4, PR.AC-6","NIST CSF V2.0: PR.AA-01, PR.AA-02, PR.AA-05"],"evidence":"/Account/Security","remediation":{"status":"Remediated","detail":"Finding: 'MFA — No'. Remediated by implementing TOTP MFA (enrollment, QR provisioning, encrypted secret storage, and a login second-factor challenge)."}},{"id":"2290","question":"Does your product support Single Sign-On (SSO), such as SAML or OIDC, for customer users logging into your system?","answer":"No","options":["Yes","No"],"status":"Planned","notes":"SAML/OIDC SSO is on the roadmap. In the interim, password policy and MFA have been strengthened: minimum 8 characters with upper/lower/number complexity, TOTP MFA, brute-force lockout, and forced password change on reset.","frameworks":["NIST CSF V2.0: PR.AA-01, PR.AA-03"],"remediation":{"status":"In Progress","detail":"Finding: 'Rectify MFA, Password updates, and complexity'. MFA and password complexity/updates are remediated; enterprise SSO (SAML/OIDC) is planned."}},{"id":"iam-complexity","question":"What password complexity configurations and settings are available?","answer":"Minimum 8 characters requiring at least one uppercase letter, one lowercase letter, and one number.","status":"Implemented","notes":"Enforced centrally on account creation, password reset, and password change (config.security.minPasswordLength; validatePassword). Length is configurable per deployment.","frameworks":["NIST CSF V1.1: PR.AC-6","NIST CSF V2.0: PR.AA-02"],"evidence":"/Account/ChangePassword"},{"id":"iam-lockout","question":"Is there lockout for failed login attempts? What are the lockout settings?","answer":"Yes — accounts lock after 10 consecutive failed attempts for 15 minutes (both configurable).","status":"Implemented","notes":"AccessFailedCount is incremented on each failed sign-in; on reaching the threshold LockoutEnd is set and further attempts are refused until it elapses. A successful sign-in resets the counter.","frameworks":["NIST CSF V1.1: PR.AC-6","NIST CSF V2.0: PR.AA-02"]},{"id":"iam-rbac","question":"Does your system/service support role-based access controls/rights that may be applied to customer accounts?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Role-based access control (Administrator, NEDOCS, manager, User) is enforced by middleware on every protected route. Hospital-scoped data isolation ensures users only see their own organization's data (least privilege).","frameworks":["NIST CSF V1.1: PR.AC-1, PR.AC-4, PR.AC-6","NIST CSF V2.0: PR.AA-02, PR.AA-05"]},{"id":"iam-least-privilege","question":"Is the principle of least privilege applied when provisioning customer accounts?","answer":"Yes","options":["Yes","No","N/A"],"status":"Implemented","notes":"Accounts receive only the roles required for their job function; hospital data is logically segregated per tenant.","frameworks":["NIST CSF V2.0: PR.AA-01, PR.AA-02, PR.AA-05"]},{"id":"iam-timeout","question":"Does your application force a timeout for inactivity? Is the timeout customer-configurable?","answer":"Yes — a 30-minute idle timeout is enforced and is customer-configurable.","options":["Yes","No"],"status":"Implemented","notes":"Authenticated sessions are invalidated after 30 minutes of inactivity (SESSION_IDLE_TIMEOUT_MINUTES). Session cookies are HTTP-only, SameSite=Lax, and Secure in production, with an 8-hour absolute lifetime.","frameworks":["NIST CSF V2.0: PR.AA-05"]},{"id":"iam-concurrent","question":"Does your product implement restrictions on concurrent user sessions and detect unauthorized access?","answer":"Yes — server-side session store with per-user session tracking; policy prohibits shared/generic accounts.","options":["Yes","No"],"status":"Implemented","notes":"Sessions are stored server-side in MongoDB; the acceptable-use policy prohibits generic/group email accounts as primary account identities.","frameworks":["NIST CSF V2.0: DE.CM-03"]}]},{"id":"crypto","section":"InfoSec","category":"Cryptographic Controls","overview":"Data is protected in transit and at rest using industry-standard cryptography. Credentials are never stored in plaintext.","highlights":["TLS 1.2+ and HSTS for all web, API, and HL7 traffic","AES-256-GCM field encryption for sensitive columns (MFA secrets, phone numbers, verification codes) plus encrypted hosting volumes","Passwords stored as PBKDF2-HMAC-SHA256 hashes; password-reset tokens stored as SHA-256 digests only","Application encryption keys provisioned via secrets management following NIST SP 800-57 guidance"],"items":[{"id":"2291","question":"Does your product/service encrypt data at rest?","answer":"Yes","options":["Yes","No"],"status":"Remediated","notes":"Data is encrypted at rest at two layers: (1) application-layer field encryption using AES-256-GCM for sensitive fields (MFA/TOTP secrets, phone numbers, one-time verification codes), keyed by a 256-bit data key (DATA_ENCRYPTION_KEY); and (2) full-volume/database encryption provided by the hosting tier. Password material is stored only as PBKDF2-HMAC-SHA256 hashes (100k iterations); reset tokens as SHA-256 digests.","frameworks":["HIPAA Security § 164.312(a)(2)(iv)","NIST CSF V1.1: PR.DS-1","NIST CSF V2.0: PR.DS-01"],"evidence":"/Legal/Trust#crypto","remediation":{"status":"Remediated","detail":"Finding: 'Encryption at rest requirement — No'. Remediated by adding AES-256-GCM field-level encryption for sensitive data and confirming hosting-tier volume/database encryption."}},{"id":"crypto-transit","question":"Does your product/service encrypt data in transit? Do you use TLS 1.2 or later?","answer":"Yes — TLS 1.2+ for all web and API traffic.","options":["Yes","No"],"status":"Implemented","notes":"All traffic is served over HTTPS/TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enabled in production. HL7/EHR ingestion requires TLS 1.2+.","frameworks":["HIPAA Security § 164.312(a)(2)(iv)","NIST CSF V1.1: PR.DS-2","NIST CSF V2.0: PR.DS-02"]},{"id":"crypto-keys","question":"Is your organization responsible for managing encryption keys for this product/service?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Application data keys are provisioned via secrets management (environment-injected, never committed) and rotated per policy. Hosting-tier keys are managed by the cloud provider's KMS. Guidance follows NIST SP 800-57.","frameworks":["NIST SP 800-57 Part 1 Rev. 5"]},{"id":"crypto-aitraining-rest","question":"Is AI training/inference data encrypted at rest using industry-standard encryption (e.g., AES-256)?","answer":"Yes — AES-256 at rest; TLS 1.2+ in transit.","options":["Yes","No"],"status":"Implemented","notes":"AI features send de-identified/synthetic operational inputs only; any retained data is encrypted with AES-256 at rest and TLS 1.2+ in transit.","frameworks":["NIST AI RMF: MAP 4.1"]}]},{"id":"appsec","section":"InfoSec","category":"Application Security","overview":"Security is built into how we develop, deploy, and operate the platform. External interfaces are authenticated and validated.","highlights":["Secure SDLC: peer code review, dependency review, pre-production code scanning, staged deployment, and rollback","Server-side input validation, parameterized database access, and output encoding in templates","REST and HL7 ingest APIs authenticated with per-hospital API keys over TLS (documented OpenAPI spec)","Sensitive identifiers are never placed in URLs; evaluation tier processes no PHI","Architecture and data-flow diagram published on this page","Pre-production static analysis active today; continuous production DAST capability being onboarded"],"items":[{"id":"2287","question":"Can you provide a data flow diagram showing the relationships of principal parts/functions and the flow of data and communications?","answer":"Yes","options":["Yes","No"],"status":"Remediated","notes":"A system architecture and data-flow diagram is published on the Trust Center. It shows browser/EHR clients, the TLS boundary, the Express application tier, network segmentation between the public marketing site and the authenticated app, the MongoDB data tier with encryption at rest, and the external LLM inference boundary (de-identified inputs only).","frameworks":["NIST CSF V1.1: DE.AE-1","NIST CSF V2.0: ID.AM-03"],"evidence":"/Legal/Trust#data-flow","remediation":{"status":"Remediated","detail":"Finding: 'Block Diagram — No'. Remediated by publishing a data-flow/architecture diagram on the Trust Center."}},{"id":"appsec-sdlc","question":"Do you incorporate security (controls, processes, training) as part of your Software Development Lifecycle (SDLC)?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Security is embedded in the SDLC: peer code review, automated code scanning before production, dependency review, staged test-before-production deployment, and rollback procedures via the change-management process.","frameworks":["NIST CSF V1.1: PR.IP-2","NIST CSF V2.0: PR.PS-06"]},{"id":"appsec-input-validation","question":"Do you implement controls to ensure data accuracy, such as integrity checks, input and data validation?","answer":"Yes — integrity constraints, access controls, input validation, and data validation.","options":["Integrity constraints","Access controls","Input validation","Data validation"],"status":"Implemented","notes":"Server-side input validation, parameterized database access, output encoding in templates, and CSRF-resistant session cookies (SameSite).","frameworks":["NIST CSF V1.1: PR.DS-6","NIST CSF V2.0: PR.DS-01"]},{"id":"appsec-no-confidential-url","question":"Does the solution exclude confidential information from URLs (e.g., date of birth, medical record number, account number)?","answer":"Yes","options":["Yes","Solution does not use URLs","No"],"status":"Implemented","notes":"Sensitive identifiers are never placed in URLs; the evaluation tier processes no PHI."},{"id":"2294","question":"Is your product/service scanned by a dynamic application security scanning (DAST) tool while in production?","answer":"In progress","options":["Yes","No"],"status":"In Progress","notes":"Static analysis and automated code scanning run pre-production today (compensating control). A continuous DAST capability against the production surface is being onboarded.","frameworks":["NIST CSF V1.1: DE.CM-8","NIST CSF V2.0: ID.RA-01"],"remediation":{"status":"In Progress","detail":"Finding: 'SDLC deficient — DAST No'. Compensating control: pre-production SAST/code scanning. DAST tooling for the production environment is being integrated."}},{"id":"appsec-api","question":"Do you provide APIs for your product/service? Describe the security model and controls.","answer":"Yes — REST + HL7 ingest APIs authenticated by per-hospital API keys (Bearer/X-API-Key), TLS 1.2+.","options":["Yes","No","Not Applicable"],"status":"Implemented","notes":"Documented OpenAPI 3.1 spec at /api/openapi.json. Each hospital is issued a scoped API key; keys are managed in Settings and can be rotated/revoked. PHI is not persisted — only synthesized flow metrics.","evidence":"/api/openapi.json"}]},{"id":"logging","section":"InfoSec","category":"Event Logging","overview":"Security-relevant activity is logged for monitoring, investigation, and compliance evidence.","highlights":["Authentication, MFA, lockout, agreement acceptance, and HL7 ingestion events are logged with actor, timestamp, source, and outcome","Immutable agreement-acceptance audit records; logs suitable for SIEM forwarding","User activity logs retained at least one year; system logs retained one year or more"],"items":[{"id":"log-what","question":"Which event log details are captured by your product or service? (Select all that apply)","answer":"Success/failure of the event, event source, event date/timestamp, where the event occurred, identity of the user/subject, and event type.","options":["Success or Failure of the event","Event Source","Event Date/Timestamp","Where event occurred","Identity of user/subject of event","Event Type"],"status":"Implemented","notes":"Server-side request logging, authentication events (including MFA and lockout), agreement-acceptance audit records, and HL7 ingestion events are captured with source, timestamp, actor, and outcome.","frameworks":["NIST CSF V1.1: PR.PT-1, DE.AE-3","NIST CSF V2.0: DE.AE-03, PR.PS-04"]},{"id":"log-tamper","question":"Does your organization validate that logs are not tampered with? What controls are in place?","answer":"Yes — append-only audit collections and immutable agreement-acceptance records; SIEM-forwardable.","options":["Yes","No","Not applicable"],"status":"Implemented","notes":"Agreement-acceptance records (timestamp, user, IP, user-agent, version) are stored in an immutable audit collection. Logs can be forwarded to a customer SIEM.","frameworks":["NIST CSF V1.1: PR.PT-1","NIST CSF V2.0: PR.PS-04"]},{"id":"log-retention","question":"How long does the product/service retain user activity and system logs?","answer":"User activity logs: at least 1 year. System logs: 1 year or more.","options":["6 years or more","At least 1 year but less than 6 years","Less than 1 year"],"status":"Implemented","frameworks":["NIST CSF V2.0: PR.PS-04"]}]},{"id":"data-mgmt","section":"InfoSec","category":"Data Security Management","overview":"Customer data is hosted in the United States, logically isolated per hospital, and collected with data minimization by design.","highlights":["Primary and backup data hosted within the United States (Los Angeles, California)","Logical tenant segregation — each hospital's data scoped by access controls","Evaluation tier contractually prohibits PHI; non-production environments use synthetic or de-identified data","HL7 and API inputs yield synthesized operational metrics — patient names, DOB, and full MRNs are not persisted","Data destruction aligned with NIST SP 800-88 media sanitization guidelines","Encryption at rest and in transit, egress restrictions, and environment monitoring while enterprise DLP tooling is evaluated"],"items":[{"id":"data-location","question":"Where is your primary and backup data center located for US-based customers?","answer":"Within the United States (Los Angeles, California; distributed/redundant backup within the US).","options":["Within the United States","Outside the United States"],"status":"Implemented","frameworks":["NIST CSF V1.1: PR.IP-5","NIST CSF V2.0: PR.IR-02"]},{"id":"data-segregation","question":"Is each customer's data physically or logically segregated from other customers' data?","answer":"Logically segregated (per-hospital tenancy and access scoping).","options":["Physically segregated","Logically segregated","Not applicable"],"status":"Implemented"},{"id":"data-nonprod","question":"Is any production data used in non-production environments?","answer":"No — non-production uses synthetic/de-identified data.","options":["Yes","No"],"status":"Implemented"},{"id":"data-destruction","question":"Does your data destruction process follow NIST SP 800-88: Guidelines for Media Sanitization?","answer":"Yes","options":["Yes","No","N/A"],"status":"Implemented","frameworks":["NIST SP 800-88"]},{"id":"2292","question":"Does the organization protect customer data with a data loss prevention (DLP) solution and monitor for suspicious activity?","answer":"In progress","options":["Yes","No"],"status":"In Progress","notes":"Compensating controls in place today: least-privilege access, encryption at rest and in transit, egress restrictions, and monitoring/alerting on the hosted environment. A dedicated DLP tool is being evaluated.","remediation":{"status":"In Progress","detail":"Finding: 'DLP — No'. Compensating controls documented; dedicated DLP tooling under evaluation."}}]},{"id":"vuln","section":"InfoSec","category":"Threat / Vulnerability Management","overview":"Vulnerabilities are scanned, prioritized, and remediated on a defined schedule. The hosted environment is protected at the network perimeter.","highlights":["Continuous automated dependency and vulnerability scanning","Firewall, web application firewall, and IDS/IPS protecting the hosted environment","Critical vulnerabilities (CVSS 9–10) remediated within 24 hours; others within 30 days","Responsible disclosure contact published on this page and the Compliance page","Internal security testing and pre-production scanning active; independent third-party penetration test scheduled"],"items":[{"id":"2293","question":"Has a third party conducted a penetration test on your product or service within the last year?","answer":"Scheduled","options":["Yes","No"],"status":"Planned","notes":"An independent third-party penetration test is scheduled. Compensating controls today: internally conducted testing, automated vulnerability scanning, and pre-production code scanning. Results will be available to customers under NDA.","frameworks":["NIST CSF V1.1: ID.RA-1, ID.RA-2, ID.RA-3, ID.RA-5, DE.CM-8","NIST CSF V2.0: ID.RA-01, ID.RA-02, ID.RA-03, ID.RA-05"],"remediation":{"status":"Planned","detail":"Finding: 'No 3rd party testing'. Third-party penetration test scheduled; interim internal testing + scanning in place."}},{"id":"vuln-remediation","question":"What is your policy for remediation of critical vulnerabilities (CVSS 9-10) and non-critical (<9)?","answer":"Critical (CVSS 9-10): within 24 hours. Non-critical (<9): within 30 days.","options":["Within 24 hours","Within 5 days","Within 14 days","Within 30 days"],"status":"Implemented","frameworks":["NIST CSF V2.0: ID.RA-01"]},{"id":"vuln-scanning","question":"Do you perform vulnerability scans of your product/service? How often?","answer":"Yes — continuous/automated dependency and vulnerability scanning.","options":["Continuous/automated","Weekly","Monthly","Quarterly"],"status":"Implemented","frameworks":["NIST CSF V1.1: PR.IP-12, DE.CM-8","NIST CSF V2.0: ID.RA-01"]},{"id":"vuln-waf-firewall","question":"Is the operating environment protected by a firewall, WAF, IDS/IPS, and monitored for suspicious activity?","answer":"Yes — firewall, web application firewall, and IDS/IPS protect the hosted environment.","options":["Yes","No"],"status":"Implemented","frameworks":["NIST CSF V1.1: PR.PT-4","NIST CSF V2.0: PR.IR-01"]},{"id":"vuln-report","question":"Do you provide a capability for users/researchers to report security vulnerabilities?","answer":"Yes — security contact published on the Trust Center and Compliance page.","options":["Yes","No"],"status":"Implemented","evidence":"/Legal/Trust#contact"}]},{"id":"change-mgmt","section":"InfoSec","category":"Updates / Change Management","overview":"Changes to production follow a documented process with review, validation, and the ability to roll back.","highlights":["Peer-reviewed changes validated in a test environment before production deployment","Automated pre-deploy code scanning on every release","Controlled deployment with health checks and rollback procedures"],"items":[{"id":"change-process","question":"Do you follow a documented change/release management process with approvals and rollback?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Changes are peer-reviewed, validated in a test environment before production, deployed via a documented process, and support rollback. Unauthorized changes are detectable via version control and deployment controls.","frameworks":["NIST CSF V1.1: PR.IP-3, PR.MA-1","NIST CSF V2.0: ID.AM-08, ID.RA-07, PR.PS-01"]},{"id":"change-code-scan","question":"Is your code scanned by an automated code scanning tool before being put into production?","answer":"Yes","options":["Yes","No","N/A"],"status":"Implemented","notes":"AI-assisted and automated code scanning run before production; AI-generated code is reviewed and validated against secure-development standards.","frameworks":["NIST CSF V1.1: DE.CM-4, DE.CM-5, DE.CM-8","NIST CSF V2.0: DE.CM-09, ID.RA-01"]}]},{"id":"compliance","section":"InfoSec","category":"Security Compliance","overview":"NEDOCS aligns with major healthcare and security frameworks and maintains independent attestation.","highlights":["SOC 2 Type II completed — Security, Availability, and Confidentiality (report available under NDA)","Frameworks applied: NIST CSF, HIPAA Security Rule, SOC 2, and CIS Critical Security Controls","Legal and regulatory compliance reviewed at least annually"],"items":[{"id":"2288","question":"In the past year, has your organization completed a SOC 2 Type 2 control report?","answer":"Yes, within the past year","options":["Yes, within the past year","Not within past year, but older report is available","Initial SOC 2 Type 2 is in progress","No","N/A"],"status":"Remediated","notes":"I AM GRACE INC. has completed a SOC 2 Type II examination of the NEDOCS service covering Security, Availability, and Confidentiality Trust Services Criteria. The report attests that controls were suitably designed and operated effectively throughout the examination period. Available to qualified customers and assessors under NDA on request.","frameworks":["SOC 2"],"evidence":"/Legal/Compliance#soc2","remediation":{"status":"Remediated","detail":"Finding: 'SOC assessment not completed'. Remediated — SOC 2 Type II examination completed; report available under NDA."}},{"id":"frameworks-used","question":"Which cybersecurity standards, frameworks, or best practices are leveraged? (Select all that apply)","answer":"HIPAA Security, NIST (CSF v2.0 / SP 800 series), SOC 2, CIS Critical Security Controls.","options":["CIS","HIPAA Security","ISO/IEC 27001","NIST","PCI-DSS","SOC 2"],"status":"Implemented","frameworks":["NIST CSF V2.0","HIPAA Security Rule","SOC 2","CIS Controls"]},{"id":"annual-review","question":"Does your organization review and verify compliance with applicable legal/regulatory requirements at least annually?","answer":"Yes","options":["Yes","No"],"status":"Implemented","frameworks":["NIST CSF V1.1: ID.GV-3, PR.IP-5","NIST CSF V2.0: GV.OC-03, PR.IR-02"]}]},{"id":"legal","section":"Vendor-GRC","category":"Legal / Regulatory","overview":"Contractual and regulatory boundaries govern how data enters the platform and how vendors handle it.","highlights":["HIPAA business-associate ready — evaluation tier is contractually no-PHI; production PHI requires an executed BAA","Sub-processors bound by confidentiality and data-protection agreements; BAAs where PHI is in scope","Employees sign confidentiality agreements as a condition of employment","US headquarters: Century City, California","GDPR, UK GDPR, and US state privacy rights addressed in the Privacy Policy"],"items":[{"id":"2285","question":"Is your organization a Business Associate (BA) as defined by HIPAA?","answer":"Yes, when a BAA is executed — NEDOCS is HIPAA business-associate ready.","options":["Yes","No"],"status":"Informational","notes":"Clarification: NEDOCS is designed as a HIPAA business-associate-ready service. The self-serve evaluation tier operates without PHI (attested at signup and re-acceptance). When a hospital moves to production use with PHI, I AM GRACE INC. executes a Business Associate Agreement and acts as a Business Associate under 45 CFR 160.103. Data-input sensitivity and the no-PHI evaluation boundary are documented in the Compliance page and Privacy Policy.","frameworks":["45 CFR 160.103","NIST CSF V2.0: GV.OC-01, GV.OC-03, GV.OC-05"],"evidence":"/Legal/Compliance#hipaa","remediation":{"status":"Remediated","detail":"Finding: 'HIPAA compliance — please clarify and update'. Clarified: BA-ready; evaluation tier is contractually no-PHI; BAA executed for production PHI use."}},{"id":"2286","question":"Does your organization require NDAs or confidentiality agreements with third-party vendors when confidential, sensitive, or PII will be disclosed?","answer":"Yes","options":["Yes","No","Not Applicable"],"status":"Remediated","notes":"Material sub-processors and vendors that may access confidential or personal data are bound by written confidentiality and data-protection agreements; where PHI is in scope, business-associate or equivalent contractual protections apply. Employees also sign confidentiality agreements as a condition of employment.","frameworks":["NIST CSF V1.1: ID.SC-3","NIST CSF V2.0: GV.SC-05"],"evidence":"/Legal/Compliance#subprocessors","remediation":{"status":"Remediated","detail":"Finding: 'Update documentation on data input and sensitivity'. Documented vendor NDA/confidentiality requirements and data-input sensitivity boundaries."}},{"id":"hq-location","question":"Is your company's headquarters located within the United States?","answer":"Yes — Century City, California, USA.","options":["Yes","No"],"status":"Implemented","frameworks":["NIST CSF V2.0: PR.IR-02"]},{"id":"gdpr","question":"Is your organization required to be compliant with the EU GDPR?","answer":"Addressed — the Privacy Policy covers GDPR/UK GDPR rights and transfer safeguards.","options":["Yes","No"],"status":"Informational","frameworks":["GDPR","NIST CSF V2.0: GV.OC-03"],"evidence":"/Legal/Privacy"}]},{"id":"resilience","section":"Resiliency","category":"Operational Resilience","overview":"The platform is designed for availability with documented continuity and recovery procedures.","highlights":["Business continuity and disaster recovery plans documented, communicated, and tested at least annually","Encrypted backups taken at least daily, stored in distributed US locations; recovery tested annually","Recovery Point Objective: 2 hours or less; Recovery Time Objective: 4 hours or less","99.9% or greater availability target with 24×7 uptime monitoring"],"items":[{"id":"bcp","question":"Does your organization have documented, communicated business continuity and disaster recovery plans, tested at least annually?","answer":"Yes — BCP and DR plans are documented, communicated, and tested at least annually.","options":["Yes","No"],"status":"Implemented","frameworks":["NIST CSF V2.0: GV.OC-04, ID.IM-02, ID.IM-04, PR.IR-03, RC.RP-01"]},{"id":"backups","question":"How often are backups taken, are they encrypted, and where are they stored?","answer":"At least daily, encrypted, stored in distributed US locations; recovery tested at least annually.","options":["Hourly","Daily","Monthly"],"status":"Implemented","frameworks":["NIST CSF V1.1: PR.IP-4, PR.DS-2","NIST CSF V2.0: PR.DS-11, PR.DS-02"]},{"id":"rpo-rto","question":"What are the Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?","answer":"RPO: 2 hours or less. RTO: 4 hours or less.","options":["30 minutes or less","2 hour or less","8 hours or less","24 hours or less"],"status":"Implemented"},{"id":"sla","question":"What availability percentage is specified in your SLA? Is support available 24x7?","answer":"≥ 99.9% availability target; 24x7 monitoring of uptime/availability.","options":["Greater than or equal to 99.9%","Between 99.9% and 99.5%"],"status":"Implemented"}]},{"id":"incident","section":"Vendor-Operational","category":"Incident Response Management","overview":"Security incidents are handled through a formal response process with defined customer notification timelines.","highlights":["Documented incident response plan with severity-based triage and escalation paths","Customers notified within 24 hours of a confirmed security incident","HIPAA breach notification to covered entities per 45 CFR §164.410 where a BAA and unsecured PHI are involved"],"items":[{"id":"incident-plan","question":"Does your organization have a formal security incident management and response plan documenting activities, procedures, and roles?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Incidents are triaged by severity with defined escalation paths; incident logs are stored separately from application databases.","frameworks":["NIST CSF V2.0: RS.MA-01, RS.MA-02, RS.CO-02, RS.CO-03"]},{"id":"incident-notify","question":"Does your organization have a documented process for notifying customers of incidents, and how quickly?","answer":"Yes — customers are notified in less than 24 hours via email/support portal; PHI breaches per 45 CFR §164.410.","options":["Less than 24 hours","24 - 48 hours","48 - 72 hours","more than 72 hours"],"status":"Implemented","frameworks":["HIPAA Breach Notification Rule §164.410","NIST CSF V2.0: RS.CO-03, RC.CO-03"],"evidence":"/Legal/Compliance#incident-response"}]},{"id":"ai","section":"Artificial Intelligence (AI)","category":"AI Use & Model Governance","overview":"AI-assisted features are optional, bounded, and governed — NEDOCS does not train foundation models on customer data.","highlights":["No customer PHI or PII used to train foundation models; LLM providers contractually prohibited from training on our inputs","AI narrative features disabled by default in production","Third-party LLM called only with de-identified or synthetic inputs on the evaluation tier","OWASP LLM Top 10 mitigations documented; model output is advisory only with human-in-the-loop","RBAC, mandatory MFA, and encryption protect access to AI-related infrastructure"],"items":[{"id":"2295","question":"Did you mitigate OWASP LLM Top 10 risks during the development of your AI model?","answer":"Yes (compensating controls) — OWASP LLM Top 10 risks are addressed for our AI-assisted features.","options":["Yes","No","Not applicable"],"status":"Compensating Control","notes":"NEDOCS does not train foundation models. AI-assisted features (shift-debrief summarization, forecasting) call a third-party LLM (Anthropic) under enterprise controls with a contractual no-training commitment. OWASP LLM Top 10 mitigations in place: prompt/response handling to limit prompt injection, no PHI/PII sent in the evaluation tier (input minimization/de-identification), output is advisory only (human-in-the-loop; no automated clinical decisions), least-privilege API keys, rate limiting, and monitoring. Model inputs/outputs are treated as untrusted and validated.","frameworks":["OWASP LLM Top 10","NIST AI RMF: GOVERN 1.1, MAP 4"],"evidence":"/Legal/Trust#ai","remediation":{"status":"Remediated","detail":"Finding: 'No OWASP Compliance — lots of AI issues'. Documented OWASP LLM Top 10 mitigations and AI governance posture; foundation models are not trained on customer data."}},{"id":"ai-training-data","question":"Does your organization use customer data to train or retrain AI models? Is it anonymized?","answer":"No customer PHI/PII is used to train foundation models; any RAG/analytics inputs are anonymized/de-identified.","options":["Yes","No"],"status":"Implemented","notes":"External LLM providers are contractually prohibited from training on NEDOCS inputs/outputs.","frameworks":["NIST AI RMF: MAP 4.1"]},{"id":"ai-access-controls","question":"Are RBAC and MFA enforced to restrict access to AI training/inference data, with monitoring?","answer":"Yes — RBAC + MFA, encryption at rest/in transit, logical segmentation, and monitoring for anomalies.","options":["Yes","No"],"status":"Implemented","frameworks":["NIST AI RMF: MAP 4"]}]}]}