Security

In short

• Fostr runs on Amazon Web Services (AWS) in the United States, using only AWS services eligible for HIPAA work.
• Every user signs in with a password and a code from an authenticator app.
• Each agency's records are walled off inside the database itself, and the most sensitive fields are encrypted with a key that belongs to that agency.
• Every change, and every look at sensitive information, is written to an activity log that shows if anything was altered.
• Backups run daily, cannot be deleted early, and are copied to a second U.S. region.

1.Signing in and access

• Sign-in. Staff sign in on Fostr's own sign-in page, in the web app and in the iPad app. Behind it, Amazon Cognito, Amazon's sign-in service, checks the password and the authenticator code and connects agencies that use their own single sign-on. Fostr itself never stores passwords. Cognito also watches for stolen passwords and risky sign-ins.
• A second step, every time. Every user confirms each sign-in with a code from an authenticator app. We do not use text-message codes, because a stolen phone number can intercept them. Risky actions, such as signing a document, ask people to prove who they are again if they have not signed in recently.
• Roles. Each person has a role, such as administrator, supervisor, caseworker or read-only, and the role decides what they can do. Automated tests check every permission rule against every role.
• Only the children you work with. An agency can limit caseworkers and read-only users to the children assigned to them. Attempts to open another child's file are blocked and recorded.
• Social Security numbers are masked. Only a supervisor or administrator can reveal one, reveals are limited, and each is recorded.
• Signing out. Signing out, or removing a user, ends their sessions at once. Repeated wrong passwords lock an account for a while. An agency can also ask us to sign staff out automatically after a period of inactivity.
• A confidentiality promise. Before using Fostr, and every year after, each user accepts a confidentiality notice for case records. Fostr will not serve anyone who has not.
• Our own staff. Fostr staff cannot open case records. They use a separate support console that shows each agency's user accounts and a limited view of its activity log, and everything they do there is recorded.

2.Keeping agencies apart

Each agency's records are separated inside the database, not just by the app. Every table that holds case records uses a database feature called row-level security. Each request is tied to one agency, and the database returns only that agency's rows. A request that is not tied to an agency gets no case records at all.

The app connects to the database with an account that cannot switch this protection off. Automated tests try to read and change other agencies' records, and they must fail. The tests also switch the database protection off on purpose, to prove the app's own checks still hold on their own.

Each agency also has its own encryption keys and its own activity log.

3.Encryption

• In transit. Connections use TLS 1.2 or newer, including the app's connection to its database. Unencrypted requests are redirected or refused.
• At rest. The database, file storage, backups, cache, message queues and logs are encrypted with keys we control in AWS Key Management Service (KMS). Passwords and keys the system uses are kept in AWS Secrets Manager, never in our code.
• A second lock on the most sensitive fields. 56 fields, including Social Security numbers, dates of birth, contact details, visit notes, signatures and visit locations, are encrypted again by the app (AES-128 with a tamper check). Each agency has its own key, and that key is itself locked by the agency's own AWS key. Someone with a copy of the database would see only scrambled text in these fields.
• Names stay searchable. Some fields, such as names, must be searchable, so access controls, agency separation and the activity log protect them instead.
• On the iPad. The iPad app keeps recent case information on the device so caseworkers can work without a signal. It is protected by the iPad's built-in encryption and erased at sign-out.
• Secure destruction. When an agency leaves, we destroy its keys and have AWS delete the key that protects them. Once older backups expire, the information those keys protected cannot be read anywhere, and the agency receives a certificate of destruction.

4.Activity log and disclosure records

Fostr writes every change, every view of sensitive information, every sign-in and every security decision to an activity log. Each agency has its own. Each entry is sealed to the one before it with cryptography, so changing or removing an earlier entry breaks the seal and shows up when the log is checked. The app cannot change or delete log entries, and we keep them for at least six years.

When case information leaves Fostr, through an export, a download, a court packet or a document sent for signature, Fostr also writes a disclosure record: who released it, to whom, why, under what legal authority, and which children it was about. An agency can list every release of one child's information, which a HIPAA-covered agency can use to answer a request for an accounting of disclosures (45 CFR 164.528).

5.Protection against attacks and misuse

• Fostr runs in private networks that cannot be reached directly from the internet, behind an AWS web application firewall that blocks common attacks and known bad sources and slows down floods of requests.
• Actions that could pull out large amounts of data, such as downloads, exports, reports, searches and revealing Social Security numbers, have stricter limits, and every blocked attempt is recorded.
• Every uploaded file is scanned for malware before Fostr accepts it.

6.Backups and recovery

7.Monitoring

AWS threat detection (Amazon GuardDuty) runs across our AWS accounts, and AWS Config keeps a record of their settings. Alerts cover errors, slowdowns and security events, such as unusual numbers of Social Security number reveals or a break found in an activity log, and a failed backup raises an alert too. A separate check from outside our network tests the service every five minutes. Alerts go straight to our team by email.

8.Fixing security flaws

When a security flaw is found in Fostr or in software it uses, we fix it by a deadline set by its severity, using the industry-standard CVSS score.

Every change to Fostr is proposed and recorded as a pull request, and automated checks scan each one for leaked passwords and keys, risky code and known flaws in the libraries we use. Before any release, the full test suite, the agency-separation tests and the infrastructure tests must pass, and the tests must run every line of the server's application code, apart from a few files we exclude on purpose, such as database migrations. The libraries and base images the service is built from are locked to exact versions and checked against known fingerprints.

9.Where Fostr runs

• AWS, Northern Virginia. Fostr runs in its own AWS accounts, with logs and security audit records kept in separate accounts. Backups are copied to AWS in Oregon.
• HIPAA-eligible services only. Every AWS service that handles a record is on AWS's list of services eligible for HIPAA work. Fostr checks its own settings when it starts, and refuses to run if it is set to send files, email, sign-ins or AI requests to a service that no business associate agreement covers.
• Our staff's access. Our staff reach AWS only through single sign-on, which gives short-lived access. We do not create long-lived AWS access keys. Only people in the United States have administrative or support access to Fostr's systems, and we do not use offshore support.
• AI drafting. Fostr drafts text with Amazon Bedrock, an AWS service, using Anthropic's Claude models run by AWS in Virginia, Ohio and Oregon. Fostr will not use AWS AI services unless AWS's setting that stops it from using customer data to improve its AI is switched on. No AI model is trained on case records, and case records are never sent to a consumer AI product.
• The companies involved. Our Privacy Notice lists every company that handles personal information for us, what each one does and what each can see.

10.Compliance

11.Laws we design for

• State child-welfare confidentiality laws. Case records are confidential, and releasing them without authority can be a crime. In Massachusetts, for example, the state child-welfare department's records are protected by 110 CMR 12.00 and M.G.L. c.66A, and releasing abuse or neglect reports without authority is a crime (M.G.L. c.119 §51E). In New Hampshire, knowingly disclosing case records unlawfully is a misdemeanor (RSA 170-G:8-a). Access controls, agency separation, the confidentiality promise and the activity log all start here.
• Massachusetts data security rules (201 CMR 17.00). A written security program, access controls, encryption of personal information sent over public networks or stored on portable devices, and oversight of service providers. Our encryption uses keys of at least 128 bits, the strength Massachusetts law uses to define encrypted data (M.G.L. c.93H).
• Breach notification (state laws and HIPAA). If a breach may affect an agency's records, we tell the agency without delay, and within 48 hours of finding it, or sooner if a law or the agency's agreement requires. Fostr helps prepare the content of the notices Massachusetts law requires and, under a business associate agreement, the HIPAA breach report (45 CFR 164.410). The agency, which owns the records, sends the notices.
• Secure destruction (M.G.L. c.93I). Records holding personal information must be destroyed so they cannot be read or rebuilt when they are disposed of. Marking them "deleted" is not enough, and we apply the same standard to backups.
• Substance use treatment records (42 CFR Part 2). These have their own federal rules. We do not hold them unless the legal basis and any required consent process are settled in writing first.
• Criminal justice information (CJIS). Fostr does not connect to criminal-history systems and is not designed to hold criminal justice information.
• IRS Publication 1075, FERPA and CCWIS. These apply only if an agency's data or system brings them in, and that must be settled in writing before the data arrives.

12.Reporting a security problem

Email security@fostrtech.com. Please report privately, do not test against data that is not yours, and give us time to fix the problem before making it public.

We aim to reply within 3 business days and to fix the problem on the timelines in section 8. We welcome good-faith research reported this way and will not take action against you for it; our Terms of Service make the same exception.

13.Requesting documents

Email security@fostrtech.com for any of these:

• our security overview, or a completed security questionnaire
• our NIST 800-53 mapping and system security plan
• our incident response and disaster recovery plans
• our HIPAA Security Rule analysis
• the field-by-field list of personal information and how each field is protected
• our vulnerability policy, vendor list and accessibility report
• our certificate of insurance

Tell us which agency you are with and what your review needs. Some documents are shared under a nondisclosure agreement.