{"vendor":"I AM GRACE","legalEntity":"I AM GRACE INC","product":"GRACE — evidence-based surge response for labor & delivery","productDescription":"GRACE computes a unit acuity/staffing level (green/yellow/red/black) from volume, acuity, and staffing, forecasts escalation, and dispatches tiered surge alerts.","contact":"Attn: Compliance & Security, I AM GRACE INC","website":"https://iamgrace.baby","lastUpdated":"July 2, 2026","version":"2026.07","summary":"GRACE enforces mandatory multi-factor authentication at sign-in (email one-time code by default, optional authenticator-app TOTP), AES-256-GCM field encryption for sensitive data at rest plus TLS 1.2+ in transit, a password complexity policy, brute-force account lockout, idle-session timeout, role-based access control with hospital-level tenant isolation, and baseline security response headers (HSTS, nosniff, clickjacking protection). The evaluation tier operates without PHI; production PHI use requires an executed Business Associate Agreement.","attestation":"Responses reflect the production configuration of the GRACE service and are consistent with the public compliance reference at /compliance. Controls that are not yet fully in place are marked In Progress or Planned until the underlying evidence exists.","domains":[{"id":"iam","category":"Identity & 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":"GRACE supports MFA for all customer accounts and requires it at every production sign-in. After a correct password the user must pass a second factor before a session is issued. The default factor emails a 6-digit one-time code to the account email address; codes expire in 10 minutes and are stored only as SHA-256 hashes. Users may upgrade to an app-based TOTP authenticator (RFC 6238 — Google/Microsoft Authenticator, 1Password, Authy) by scanning a QR code; the TOTP secret is encrypted at rest with AES-256-GCM. MFA can also be scoped to specific roles by 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":"/app/settings","remediation":{"control":"Multi-factor authentication","status":"Remediated","detail":"A mandatory second-factor challenge is enforced at login (email OTP by default, optional authenticator-app TOTP) via MFA_REQUIRED_FOR_ALL in production."}},{"id":"2290","question":"Does your product support Single Sign-On (SSO), such as SAML or OIDC, for customer users logging into your system? (Password & complexity)","answer":"Password policy and lockout implemented; SSO planned","options":["Yes","No"],"status":"In Progress","notes":"Passwords are set through a complexity policy on create, change, and reset: minimum 8 characters with an uppercase letter, a lowercase letter, and a number (configurable via MIN_PASSWORD_LENGTH). Passwords are stored only as salted bcrypt hashes. Repeated failed sign-ins trigger temporary account lockout. Enterprise SSO (SAML/OIDC) is on the roadmap; until it ships, MFA-protected password authentication is the supported mechanism.","frameworks":["NIST CSF V1.1: PR.AC-6","NIST CSF V2.0: PR.AA-02"],"evidence":"/trust#iam","remediation":{"control":"Password policy & SSO","status":"In Progress","detail":"Password complexity and account lockout are enforced today; enterprise SSO (SAML/OIDC) is planned and tracked as In Progress."}},{"id":"iam-complexity","question":"What password complexity configurations and settings (case, characters, length, reuse, expiration) are available?","answer":"Minimum 8 characters requiring upper, lower, and numeric characters; configurable minimum length.","status":"Implemented","notes":"Enforced server-side on create/change/reset. Password fields are obscured in the UI. Reset and email-verification tokens are stored only as SHA-256 digests.","frameworks":["NIST CSF V1.1: PR.AC-6","NIST CSF V2.0: PR.AA-02"],"evidence":"/trust#iam"},{"id":"iam-lockout","question":"Is there lockout for failed login attempts?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"After a configurable number of failed attempts (default 10) the account is temporarily locked for a configurable window (default 15 minutes). The failed-attempt counter resets on successful authentication. The same lockout guards the MFA code-entry step against brute force.","frameworks":["NIST CSF V1.1: PR.AC-6","NIST CSF V2.0: PR.AA-02"],"evidence":"/trust#iam"},{"id":"iam-rbac","question":"Does your system/service support role-based access controls that may be applied to customer accounts?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"GRACE enforces role-based access (sysadmin, administrator, charge nurse, viewer) with least-privilege defaults. All hospital data is scoped to the authenticated user's organization (tenant isolation); users cannot read another hospital's data.","frameworks":["NIST CSF V1.1: PR.AC-1, PR.AC-4, PR.AC-6","NIST CSF V2.0: PR.AA-02, PR.AA-05"],"evidence":"/trust#iam"},{"id":"iam-timeout","question":"Does your application force a timeout for inactivity?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Authenticated sessions expire after a configurable idle period (default 30 minutes in production) enforced in middleware, and have an absolute maximum lifetime. Session cookies are HTTP-only, SameSite=Lax, and Secure in production.","frameworks":["NIST CSF V1.1: PR.AC-6","NIST CSF V2.0: PR.AA-02"],"evidence":"/trust#iam"},{"id":"iam-api-keys","question":"Describe the API security model for machine-to-machine access.","answer":"Scoped, hashed Bearer API keys per integration","status":"Implemented","notes":"Integrations authenticate with per-hospital Bearer keys (prefix grace_) that are stored only as SHA-256 hashes and carry least-privilege scopes (e.g. ingest:hl7, read:unit-state). Keys are minted and revoked by hospital admins.","frameworks":["NIST CSF V1.1: PR.AC-1, PR.AC-4","NIST CSF V2.0: PR.AA-01, PR.AA-05"],"evidence":"/developers"}]},{"id":"crypto","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 such as authenticator (TOTP) secrets, keyed by a 256-bit data key (DATA_ENCRYPTION_KEY); and (2) full-volume/database encryption provided by the hosting tier. Passwords are stored only as salted bcrypt hashes; one-time codes and setup/reset tokens are stored only 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":"/trust#crypto","remediation":{"control":"Encryption at rest","status":"Remediated","detail":"AES-256-GCM field-level encryption protects sensitive data, backed by hosting-tier volume/database encryption; secrets are never stored in plaintext."}},{"id":"crypto-transit","question":"Does your product/service encrypt data in transit? Do you use TLS 1.2 or later?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"All web and API traffic is served over HTTPS/TLS (1.2+). HSTS is enabled in production. Outbound webhooks are HMAC-SHA256 signed and delivered over HTTPS.","frameworks":["HIPAA Security § 164.312(a)(2)(iv)","NIST CSF V1.1: PR.DS-2","NIST CSF V2.0: PR.DS-02"],"evidence":"/compliance#technical-controls"},{"id":"crypto-keys","question":"Is your organization responsible for managing encryption keys for this product/service?","answer":"Yes","status":"Implemented","notes":"The AES-256 data key and session-signing secret are generated with a cryptographically secure RNG (see generate-secrets.sh), held only in the server environment file, and preserved across deployments so encrypted data remains readable. Keys are never committed to source control.","frameworks":["NIST SP 800-57 Part 1 Rev. 5"],"evidence":"/trust#crypto"}]},{"id":"appsec","category":"Application Security","items":[{"id":"2287","question":"Can you provide a diagram in which the relationships of principal parts/functions are represented as well as the flow of data and communications (e.g. data flow diagram)?","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, network segmentation between the public marketing site and the authenticated application, the MongoDB data tier with encryption at rest, scoped API-key ingestion, and the external LLM inference boundary (de-identified inputs, no training).","frameworks":["NIST CSF V1.1: DE.AE-1","NIST CSF V2.0: ID.AM-03"],"evidence":"/trust#data-flow","remediation":{"control":"Architecture & data-flow diagram","status":"Remediated","detail":"A data-flow/architecture diagram is published on the Trust Center showing clients, the TLS boundary, network segmentation, the data tier, and the LLM boundary."}},{"id":"2294","question":"Is your product/service scanned by a dynamic application security scanning tool while in production?","answer":"In progress; pre-production scanning as a compensating control","options":["Yes","No"],"status":"In Progress","notes":"Continuous dynamic application security testing (DAST) against the production surface is being implemented. In the interim, changes are scanned before release, dependencies are monitored for known vulnerabilities, and AI-assisted code review is applied in the SDLC as compensating controls.","frameworks":["NIST CSF V1.1: DE.CM-8","NIST CSF V2.0: ID.RA-01"],"evidence":"/trust#appsec","remediation":{"control":"Application security scanning","status":"In Progress","detail":"Continuous production DAST is being stood up; pre-production scanning and dependency/code review serve as compensating controls until it is live."}},{"id":"appsec-sdlc","question":"Do you incorporate security as part of your Software Development Lifecycle (SDLC)?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Changes go through version control and review before release; secrets are kept out of source; releases are validated by build and type checking. AI-generated code is reviewed and validated against secure-coding standards before deployment.","frameworks":["NIST CSF V1.1: PR.IP-2","NIST CSF V2.0: PR.PS-06"],"evidence":"/trust#appsec"},{"id":"appsec-input","question":"Do you implement controls to ensure data accuracy (input and/or data validation)?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Inbound API and ingestion payloads are validated and normalized; access controls and integrity constraints apply throughout the ingest pipeline.","frameworks":["NIST CSF V1.1: PR.DS-6","NIST CSF V2.0: PR.DS-01"],"evidence":"/developers"},{"id":"appsec-no-confidential-url","question":"Does the solution exclude confidential information (DOB, MRN, account number) from URLs?","answer":"Yes","options":["Yes","Solution does not use URLs","No"],"status":"Implemented","notes":"Identifiers are passed in request bodies or as opaque IDs, not as confidential values in URLs. The evaluation tier does not process PHI.","evidence":"/trust#appsec"},{"id":"appsec-headers","question":"What baseline web security controls are enforced?","answer":"Security response headers + clickjacking protection","status":"Implemented","notes":"Every response carries X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, a restrictive Referrer-Policy and Permissions-Policy, and (in production) HSTS with includeSubDomains and preload.","frameworks":["NIST CSF V1.1: PR.PT-4","NIST CSF V2.0: PR.IR-01"],"evidence":"/trust#appsec"}]},{"id":"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 — controls documented; AI free-text is opt-in and PHI-minimized","options":["Yes","No","Not applicable"],"status":"Compensating Control","notes":"GRACE does not train foundation models; it uses a third-party LLM (Anthropic) under enterprise API terms that contractually prohibit training on GRACE inputs/outputs. OWASP LLM Top 10 mitigations include: prompt/output handling with structured context, redaction of digit strings before inference, least-privilege scoping of AI features, per-user opt-in for sending free text to the LLM, and a no-PHI evaluation tier. AI assists clinicians; it does not make automated significant decisions about individuals.","frameworks":["OWASP LLM Top 10","NIST AI RMF: GOVERN 1.1, MAP 4"],"evidence":"/trust#ai","remediation":{"control":"LLM security controls","status":"Compensating Control","detail":"LLM controls are documented and enforced: no model training on customer data, input redaction, opt-in free text, a no-PHI evaluation tier, and enterprise no-training contract terms."}},{"id":"ai-training","question":"Does your organization use customer data to train or retrain AI models?","answer":"No","options":["Yes","No"],"status":"Implemented","notes":"GRACE does not train or retrain models on customer data. The LLM provider is contractually prohibited from training on GRACE API inputs or outputs.","frameworks":["NIST AI RMF: MAP 4.1"],"evidence":"/compliance#technical-controls"},{"id":"ai-access","question":"Are RBAC and encryption enforced around AI data paths?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"AI features are only reachable by authenticated, role-scoped users; requests are TLS-encrypted in transit; the evaluation tier is designed for non-PHI inputs.","evidence":"/trust#ai"}]},{"id":"data-mgmt","category":"Data Security Management","items":[{"id":"2292","question":"Does the organization protect customer data with a data loss prevention (DLP) solution and monitor for suspicious activity?","answer":"In progress; monitoring and breach-notification process in place","options":["Yes","No"],"status":"In Progress","notes":"Enterprise DLP tooling is being adopted. Compensating controls in place today: least-privilege access and tenant isolation, server-side request/ingestion logging for security and diagnostics, an immutable agreement-acceptance audit trail, and a documented incident-response and breach-notification process.","frameworks":["NIST CSF V1.1: DE.CM-7","NIST CSF V2.0: DE.CM-03"],"evidence":"/compliance#incident-response","remediation":{"control":"Data loss prevention & monitoring","status":"In Progress","detail":"Enterprise DLP adoption is in progress; monitoring, least-privilege access, audit logging, and a documented breach-notification process serve as compensating controls."}},{"id":"data-location","question":"Where is your primary data center located for US-based customers?","answer":"Within the United States","options":["Within the United States","Outside the United States"],"status":"Informational","notes":"Application and database infrastructure for US customers is hosted within the United States.","frameworks":["NIST CSF V1.1: PR.IP-5","NIST CSF V2.0: PR.IR-02"],"evidence":"/compliance#subprocessors"},{"id":"data-segregation","question":"Is each customer's data logically segregated from other customers' data?","answer":"Logically segregated","options":["Physically segregated","Logically segregated","Not applicable"],"status":"Implemented","notes":"All records are scoped to a hospital tenant and access is enforced by the authenticated session's hospital identifier.","evidence":"/trust#data-mgmt"},{"id":"data-nonprod","question":"Is any production data used in non-production environments?","answer":"No","options":["Yes","No"],"status":"Implemented","notes":"Non-production and demo environments use synthetic/de-identified data. The evaluation tier itself is contractually no-PHI.","evidence":"/trust#data-mgmt"}]},{"id":"logging","category":"Event Logging & Monitoring","items":[{"id":"log-what","question":"What event log details are captured by your product/service?","answer":"Authentication events, API/ingestion events, and agreement acceptances","status":"Implemented","notes":"Logged detail includes success/failure, source, timestamp, event type, and the identity of the subject where applicable. Sign-in failures drive account lockout; agreement acceptances (user, timestamp, IP, user-agent, version) are retained in an immutable audit collection.","frameworks":["NIST CSF V1.1: PR.PT-1, DE.AE-3","NIST CSF V2.0: DE.AE-03, PR.PS-04"],"evidence":"/compliance#technical-controls"},{"id":"log-retention","question":"How long does the product/service retain logs?","answer":"Operational and audit logs retained per policy","status":"Informational","notes":"Agreement-acceptance audit records are retained for contract-formation defensibility. Operational/security logs are retained per the deployment's log-management configuration.","frameworks":["NIST CSF V1.1: PR.PT-1","NIST CSF V2.0: PR.PS-04"],"evidence":"/trust#logging"}]},{"id":"vuln","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":"Planned; internal testing performed in the interim","options":["Yes","No"],"status":"Planned","notes":"A third-party penetration test is scheduled. In the meantime, internal security testing, dependency vulnerability monitoring, and pre-release scanning are performed. Pen-test results will be shared under NDA once complete.","frameworks":["NIST CSF V1.1: ID.RA-1, ID.RA-2, DE.CM-8","NIST CSF V2.0: ID.RA-01, ID.RA-02"],"evidence":"/trust#vuln","remediation":{"control":"Third-party penetration testing","status":"Planned","detail":"A third-party penetration test is scheduled; internal testing and dependency scanning are the interim compensating controls."}},{"id":"vuln-remediation","question":"What is your policy for remediation of critical vulnerabilities?","answer":"Prioritized by severity with expedited handling of critical issues","status":"Implemented","notes":"Findings are identified, prioritized, patched, tested, and deployed through the change process; critical issues are expedited. Dependencies are updated in response to advisories.","frameworks":["NIST CSF V1.1: ID.RA-1, PR.IP-12","NIST CSF V2.0: ID.RA-01"],"evidence":"/trust#vuln"},{"id":"vuln-report","question":"Do you provide a way for users or researchers to report security vulnerabilities?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Security issues can be reported to the Compliance & Security contact published on the compliance reference page.","evidence":"/compliance#contact"}]},{"id":"change-mgmt","category":"Updates & Change Management","items":[{"id":"change-process","question":"Do you follow a documented change/release management process?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Releases are version-controlled and deployed through a scripted, repeatable process with health checks; secrets (including the data-encryption key) are preserved across deploys and never rsync'd from developer machines.","frameworks":["NIST CSF V1.1: PR.IP-3","NIST CSF V2.0: PR.PS-01"],"evidence":"/trust#change-mgmt"},{"id":"change-code-scan","question":"Is your code scanned before being put into production?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Type checking and linting gate the build; dependencies are monitored for known vulnerabilities; AI-assisted review is applied to changes.","frameworks":["NIST CSF V1.1: DE.CM-8","NIST CSF V2.0: ID.RA-01"],"evidence":"/trust#change-mgmt"}]},{"id":"compliance","category":"Security Compliance","items":[{"id":"2288","question":"In the past year, has your organization completed a SOC 2 Type 2 control report?","answer":"Yes — SOC 2 Type II report available under NDA","options":["Yes, within the past year","Not within past year, but older report is available","Initial SOC 2 Type 2 is in progress","No"],"status":"Remediated","notes":"I AM GRACE INC. maintains SOC 2 Type II for the GRACE service, covering the Trust Services Criteria for Security, Availability, and Confidentiality. The report contains confidential control descriptions and is available to qualified customers and prospects under a mutual NDA.","frameworks":["SOC 2"],"evidence":"/compliance#soc2","remediation":{"control":"SOC 2 Type II","status":"Remediated","detail":"SOC 2 Type II is reflected across the compliance reference and Trust Center; the report is available to qualified customers and prospects under NDA."}},{"id":"frameworks-used","question":"Which cybersecurity standards or frameworks are leveraged by the organization?","answer":"SOC 2, HIPAA Security, NIST CSF; OWASP for application security","status":"Informational","notes":"Controls are mapped to SOC 2 Trust Services Criteria, the HIPAA Security Rule, and NIST CSF; application security references the OWASP Top 10 and OWASP LLM Top 10.","frameworks":["SOC 2","HIPAA Security","NIST CSF","OWASP"],"evidence":"/compliance"}]},{"id":"legal","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 for production PHI; evaluation tier is no-PHI","options":["Yes","No"],"status":"Implemented","notes":"GRACE is HIPAA-ready. Where a hospital submits PHI to the Service, I AM GRACE INC. acts as a business associate under an executed Business Associate Agreement. Self-serve evaluation access is contractually restricted to non-PHI operational data; users attest to the no-PHI restriction at signup and at each agreement re-acceptance.","frameworks":["45 CFR 160.103","NIST CSF V1.1: ID.BE-1, ID.GV-3","NIST CSF V2.0: GV.OC-01, GV.OC-03"],"evidence":"/compliance#hipaa","remediation":{"control":"HIPAA business-associate status","status":"Implemented","detail":"GRACE acts as a business associate under an executed BAA for production PHI; the evaluation tier is no-PHI by contract. See /compliance#hipaa."}},{"id":"2286","question":"Does your organization require NDAs/confidentiality agreements with third-party vendors if confidential, sensitive, or PII will be disclosed?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Material sub-processors are bound by written agreements restricting use of data to performing services for I AM GRACE; where PHI is in scope, sub-processors are subject to business-associate or equivalent protections. Product data inputs are de-identified/synthesized on the evaluation tier, and PII is minimized.","frameworks":["NIST CSF V1.1: ID.SC-3","NIST CSF V2.0: GV.SC-05"],"evidence":"/compliance#subprocessors","remediation":{"control":"Vendor confidentiality & data inputs","status":"Implemented","detail":"Data inputs are de-identified/synthesized on the evaluation tier, and material sub-processors are bound by confidentiality and business-associate protections."}},{"id":"hq-location","question":"Is your organization's headquarters located within the United States?","answer":"Yes","options":["Yes","No"],"status":"Informational","notes":"I AM GRACE INC. is a California corporation headquartered in the United States.","evidence":"/compliance#contact"},{"id":"data-uses","question":"Does the product use, store, or transmit PHI or PII?","answer":"Evaluation tier: no PHI. Production tier: PHI only under a BAA. PII is minimized.","status":"Informational","notes":"The evaluation tier operates without PHI. Account records contain minimal PII (name, work email). Production PHI processing requires an executed BAA.","frameworks":["NIST CSF V1.1: ID.GV-3","NIST CSF V2.0: GV.OC-03"],"evidence":"/privacy"}]},{"id":"incident","category":"Incident Response","items":[{"id":"incident-plan","question":"Does your organization have a formal security incident management and response plan?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Incident-response procedures detect, triage by severity, contain, and remediate security events, with defined escalation paths.","frameworks":["NIST CSF V1.1: RS.RP-1, RS.CO-1","NIST CSF V2.0: RC.RP-01, RS.MA-01"],"evidence":"/compliance#incident-response"},{"id":"incident-notify","question":"Does your organization have a documented process for notifying customers of incidents?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Where a breach of unsecured PHI occurs, I AM GRACE notifies the covered entity without unreasonable delay in accordance with the BAA and 45 CFR § 164.410, and complies with other applicable breach-notification laws.","frameworks":["NIST CSF V1.1: RS.CO-2","NIST CSF V2.0: RS.CO-02"],"evidence":"/compliance#incident-response"}]},{"id":"resilience","category":"Operational Resilience","items":[{"id":"bcp","question":"Do you maintain business continuity / disaster recovery capabilities?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Data is backed up and application releases are reproducible from version control and a scripted deploy, enabling recovery. Continuity and recovery procedures are maintained and reviewed.","frameworks":["NIST CSF V1.1: ID.BE-5, PR.IP-9","NIST CSF V2.0: GV.OC-04"],"evidence":"/trust#resilience"},{"id":"sla","question":"Do you monitor availability of your product or service?","answer":"Yes","options":["Yes","No"],"status":"Implemented","notes":"Service health is monitored; the deployment is fronted by a reverse proxy with process supervision and automatic restart.","evidence":"/trust#resilience"}]}]}