How to answer
Will you sign a Business Associate Agreement (BAA)?
This is a contract question wearing a compliance question's clothes. The reviewer wants to know whether you will take on Business Associate liability, and no amount of security posture answers it.
Yes. We execute a Business Associate Agreement before any protected health information is processed, and we hold BAAs with the subprocessors that would handle it. Our template is available on request.
FillTrust grades an answer like this not in your documents when your documents support it.
- Answered from
- Your contracts, not your security policies. A BAA is a signed agreement or it is nothing, and no policy document can stand in for one.
- Evidence to attach
- The executed BAA, or your template if the reviewer is asking whether you have one to offer.
- Where it is asked
- SIG LiteBespoke vendor questionnaires
Across the questionnaires we see, HIPAA comes up more often than SOC 2 does, and almost never as "are you HIPAA compliant". It arrives as two narrower questions: does your product touch protected health information, and will you sign a BAA. Answer those two and you have answered the section.
Whether you touch PHI is a question about your users, not your industry. A product that never asks for health data still receives it the moment a customer's staff paste a patient name into a support ticket, a notes field or an uploaded attachment. If you sell to hospitals, insurers, clinics or the companies that serve them, you cannot rule that out by design intent alone. The vendors who get caught here are the ones who answered "we are not a healthcare company" and were, in fact, storing PHI in free-text columns.
A BAA is a contract, not a certification. Signing one makes you a Business Associate and puts you directly under the Security Rule and parts of the Privacy Rule. That is a real legal exposure and it is reasonable to decline it. What is not reasonable is treating the question as a box to tick: reviewers who work in healthcare will follow up by asking whether you have done the Security Rule risk analysis and who your named Privacy Officer and Security Officer are. If the answer to the BAA question is yes, have answers to those ready too.
Liability flows downhill. Sign a BAA, send PHI to a subprocessor, and you now need a BAA with that subprocessor. This is the part that quietly fails. Your cloud provider will sign one, usually without argument. Your error-tracking tool, your analytics, your transactional email and your customer support platform may not, or may only on an enterprise plan you are not on. Work out which of your subprocessors would actually see PHI before you promise anything.
If you do not handle PHI, say so directly and say what stops it: no health data field in the product, contractual terms prohibiting it, or a customer-side control. "We do not process PHI and do not sign BAAs" is a clean answer that a reviewer can route around. It is far better than a hedge, because a hedge gets escalated and a clean no gets filed.
How this one goes wrong
Specific to this question, not general advice.
- Answering yes because you are secure. A BAA is a contract that assigns you liability under the Security and Privacy Rules; being well-run is not the same as having signed one.
- Claiming to be HIPAA certified. There is no such certificate, and a reviewer who works in healthcare knows it. It reads as either a misunderstanding of the rule or a willingness to overstate, and both cost you credibility on the rest of the file.
- Forgetting the subcontractors. If PHI reaches your hosting provider, your log aggregator or your email service, you need a BAA with each of them, and several of the large providers offer one only on specific plans.