The model
Every Buzz message is encrypted with its own key, wrapped separately to each recipient.
The mechanism matters more than the adjective, so here is the mechanism.
Buzz uses participant-scoped envelope encryption. Each message is encrypted with a key of its own, and that key is then wrapped separately to the public key of every person entitled to read the message. Entitlement is therefore not a setting that sits beside the message. It is the set of wrapped keys that exist for it.
A Buzz account holds a key pair. The private half of that pair is wrapped under a combination of the account's email address and a passphrase. The passphrase is separate from the login password, and it is not a secret Skyscape holds at rest.
Message bodies are decrypted in your browser for display. A Buzz conversation is not plaintext rendered on a server and sent down to you.
- One key per message — the key that protects a message protects that message only.
- Wrapped per recipient — each participant gets their own wrapped copy of the message key, created for them and readable with their private key.
- Ciphertext in the database — message bodies are stored as ciphertext, and the per-recipient wrapped keys sit apart from them. A database dump is not a readable transcript.
- Decrypted in the browser — display happens on your device, from ciphertext your device received.
- A passphrase, not the password — the private key is wrapped under the account's email together with a passphrase that Skyscape does not hold at rest.
- Encryption in transit and at rest — messages, documents and images, on the wire and on disk.
What that buys you
Three practical consequences an administrator can take into a risk analysis.
Where the boundary sits
Skyscape is inside the trust boundary, as your business associate.
Several Buzz features cannot work unless a server reads message content, and Buzz does not pretend otherwise.
When you unlock Buzz, Skyscape's servers are able to unwrap your private key, and they decrypt content where a product feature requires it. Four operations work that way today.
- Search — finding a message in your own history means something has to read the messages being searched.
- File download — delivering a document or an image to the device that asked for it.
- Sharing past messages — when a person is added to an existing conversation and your organization has chosen to let them see what came before, that history has to be made readable to them.
- BuzzLink previews — the no-login guest experience described in the next section.
So the correct way to describe Skyscape is as a business associate that can access message content, under the BAA, for those operations. That is what your privacy officer should write into your risk analysis, and it is what we will confirm in writing if asked.
If your organization needs a vendor whose machines could not read content under any circumstances, Buzz is not that product. We would rather you learn that on this page than in month four of a rollout.
The words we do not use
Two phrases you will not find on this page, and why.
Almost every vendor security page in this market uses at least one of them. We have taken both off ours.
A provider that cannot read your content
The first claim describes a system in which the provider's machines never hold your private key in the clear, so the provider could not read a message even if it wanted to, and even if somebody insisted.
Buzz does not meet that description. Our servers do hold the clear private key at unlock, because that is what makes search across your own history and file download work.
Encryption sealed from one device to another
The second claim describes content sealed on one participant's device and opened only on another participant's device, with no point in between at which anything is decrypted.
Buzz does not meet that description either. The four operations named in the previous section decrypt content on our servers, by design, and naming them is the whole point of this page.
A vendor that advertises either posture while running a server-side search index is claiming something its architecture does not support. The claim survives a sales call. It does not survive a security review, and when it falls over, the reviewer does not simply strike that line. They re-check everything else the vendor said, including the parts that were true.
We would rather hand your reviewer a smaller statement that holds. The statement is this: participant-scoped envelope encryption, message bodies stored as ciphertext and decrypted in your browser for display, and Skyscape inside the trust boundary as your business associate, decrypting content on the server for four named features. Every sentence of that will still be true at the end of your diligence.
If a questionnaire asks whether Buzz meets one of the two descriptions above, answer no, and send the reviewer here. That answer costs you nothing and it is the one we will give too.
A customer can hold us to the exact wording on this page, which is the reason it is worded this way.
Everything on this page is written so that it can be repeated verbatim in a security questionnaire, a vendor risk assessment or a board paper without needing a footnote later.
The named exception
BuzzLink reaches people with no account, and that costs something.
BuzzLink gives a patient or a family member access to a conversation with no login. There is nothing for that guest to install, no account to create and no password to invent, which is the entire reason it works for the people it is built for.
It also means there is no secret of theirs for Buzz to wrap keys under. The keys for a BuzzLink guest are derivable by the server, by design. That is a weaker posture than a Buzz user's own account, and we are not going to describe it as anything else.
We think the trade is usually worth making. A daughter in a parking lot with a phone and a link is reachable. The same daughter asked to create an account, choose a passphrase and install an app is, in practice, not reachable, and the clinical conversation moves to a channel nobody governs at all.
What we ask is that you evaluate BuzzLink as its own decision rather than letting it inherit the rest of this page. It is one of the four operations in which content is decrypted on our servers, it is covered by the same business associate agreement as everything else in Buzz, and your administrators control whether and where it is used.
See how BuzzLink works for the product side of it: what a guest sees, what they can do and who can start one.
HIPAA, the BAA and SOC 2
What Skyscape signs, and what an examiner has already looked at.
Two different things, and they are worth keeping apart.
An attestation report is an examiner's opinion on named controls, which is a different kind of document from a badge, and the difference matters when you are reading ours.
A SOC 2 engagement produces a report written by an independent accounting firm. The firm examines a described set of controls and renders an opinion on them. Skyscape's opinion is unqualified, which means the examiner took no exception to the description of the system, to the design of the controls or to how they operated over the period examined.
The scope is what to read closely in any such report, including ours. Ours covers controls relevant to the Security Trust Services Criteria. We name that scope in the copy above on purpose: a report cited with no scope at all invites a reader to assume the widest one.
The report itself is available to a prospective customer on request, alongside the business associate agreement, and your reviewer is welcome to both before you commit to anything.
Identity and organizational control
One account per named person, and your directory decides who has one.
Encryption protects content. Identity decides who is a participant in the first place, which is the control that actually governs access.
Who a person is
- One account per named person — shared logins are not permitted, and each workforce member gets a unique user identifier, as HHS guidance requires. An account that stands for a shift or a station rather than a person defeats every other control on this page.
- Single sign-on through your own identity provider — your organization authenticates its own people, with your password policy, your second factor and your session rules.
- Credentials are entered on your login page — a person signing in through single sign-on types their password into your identity provider's page, not into a Buzz form.
- Just-in-time provisioning — a person who should have an account gets one on first sign-in, rather than waiting for somebody to create it by hand.
- Leaving the directory removes access — when your identity provider stops vouching for a person, Buzz stops letting them in. Offboarding happens where you already do it.
Who decides what
- Administrators govern membership — they invite, add and remove people, and a person who leaves the organization loses access to its conversations.
- Administrators govern roles and policy — what a role may do, and the organization-level settings that every linked space inherits, are set once by your administrators rather than chosen by each user.
- A super admin stands behind the administrator — a standing backup, so an unplanned absence is an inconvenience rather than an outage of authority over your own account.
- Activity is auditable — administrative and conversation activity can be reviewed, which is what an investigation after the fact actually needs.
BuzzSpace is where the organization-level settings and the roles are described in detail.
Questions a security reviewer asks
Can Skyscape read our messages?
For the four named operations, yes. Search, file download, sharing past messages with a person added to a conversation, and BuzzLink previews all require content to be decrypted on our servers, which is why Skyscape operates as your business associate under a BAA rather than claiming to be unable to see anything. Outside those operations, message bodies sit in the database as ciphertext and are decrypted in your browser for display.
Our questionnaire has a box for the strongest form of message encryption. How do we answer it?
Accurately, and in the negative. Buzz is neither a system whose provider's machines never hold the clear private key, nor one in which content is sealed device to device with nothing decrypting in between. Both descriptions are incompatible with server-side search and file download, which Buzz provides deliberately. Point the reviewer at the boundary section of this page and at the section on the terms we refuse.
What stops a stolen copy of the database from being read?
Message bodies are stored as ciphertext, and the per-recipient wrapped keys sit apart from them, so a dump of the message store is not a readable transcript of what your clinicians said. That is the property the model is built to provide and it is the one we will stand behind.
What is the passphrase, and how is it different from our password?
The login password authenticates a person. The passphrase is a separate secret, and a normal account's private key is wrapped under a combination of the account's email address and that passphrase. Skyscape does not hold the passphrase at rest. Your administrators should treat it as part of onboarding and explain it to staff in those terms.
How is BuzzLink different, and can we turn it off?
BuzzLink reaches a patient or family member with no login at all, so there is no guest secret and the keys for that guest are derivable by the server, by design. It is a different posture from a Buzz user's own account and should be decided separately in your risk analysis. Where and whether it is used is an organizational policy decision, set by your administrators.
Exactly what does your SOC 2 report cover?
It is a SOC 2 Type 2 attestation report for the Buzz service, covering controls relevant to the Security Trust Services Criteria, with an unqualified opinion from the examining firm. It is a report containing an opinion, not a badge awarded by a standards body, and we are precise about that because a reviewer who catches a vendor being loose with it starts re-checking everything else. The report is available on request.
Will you sign a business associate agreement?
Yes. Buzz is built as a HIPAA-secure platform and Skyscape offers a business associate agreement through its sales team. Ask for it during evaluation rather than after: the BAA is what turns the boundary described on this page into a contractual obligation, and reading it is the fastest way to understand what Skyscape may and may not do with your content.
What happens when somebody leaves our organization?
Access ends where your directory ends. When your identity provider stops vouching for a person they can no longer sign in, and an administrator removing them from the organization removes their access to its conversations. Because every person has their own account, there is no shared credential left behind for them to keep using.
Can we review the report and the agreement before we buy?
Yes. The attestation report is available to a prospective customer on request, the business associate agreement is available through the sales team, and this page is written so that it can be quoted verbatim in your assessment. If your reviewer needs a working session with someone who knows the architecture rather than a document, ask for one.
The rest of the platform
Security is a property of the whole platform, not a module.
Start here
The Buzz platform
Every module on one page: the conversations, the spaces, the reference layer, the documents and the bridges to the systems your agency already runs. Each one sits inside the posture described here.
See the platformBuzzChat
One-to-one and group messaging, with addressing and acknowledgement in the message.
See BuzzChatBuzzSpace
Spaces that belong to the organization, with roles and policy set once and inherited.
See BuzzSpaceBuzzLink
Reaching a patient or a family member with no account, and the exception that comes with it.
See BuzzLinkBuzzStreams
The bridge to the EHR and the other systems an agency runs.
See BuzzStreamsStart here
Bring us the questionnaire that killed your last vendor.
Send us the security review that stopped a project, and we will answer it line by line in front of you, including the lines where the answer is no. Twenty minutes, your reviewer, our architecture.