{"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":"This questionnaire is the authoritative, structured record of NEDOCS's security and privacy posture for hospital procurement, security reviewers, and automated assessment agents. It maps each vendor-assessment question to NEDOCS's canonical answer, the implementing control, and (where applicable) the remediation status for items raised in a corrective action plan. The evaluation tier operates without PHI; production PHI use requires a separately executed Business Associate Agreement (BAA).","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","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","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","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","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","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","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","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","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","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","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","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","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"]}]}]}