A policy is not a control
The most common answer we hear to the email question is that the company has a policy against putting controlled data in email. That is a reasonable sentence and a poor control. It fails because it tells people what not to do without telling them what to do instead. A program engineer at your customer needs a revised drawing today, has your address, and does not have an account in your portal. The policy loses that argument every time, and it loses it quietly, in a thread nobody reviews.
The fix is not a stricter policy. It is a sanctioned path that is faster than the unsanctioned one. Every design decision in this article comes back to that principle, because a compliant workflow people avoid is a boundary that exists only on paper — and an assessor interviewing your engineers will find that out in about four minutes.
It helps to be clear about what mail and file sharing actually are in scoping terms. If controlled unclassified information passes through them, they process or transmit CUI, which puts them in the assessed category along with everything that supports them: the identity provider, the endpoint management platform, the logging system. If they are kept clear of CUI by policy and procedure that actually holds, they can be documented and risk-managed instead. That single distinction is worth a great deal of money, and it is decided by design rather than by intention.
You are probably here because
- Somebody told you that you need a government tenant and you want to know whether that is true
- A drawing arrived by email this morning and you are not sure what to do about it
- Your file sharing has anonymous links turned on and nobody knows who created them
- You want to keep mail outside the assessment boundary and are not sure it is possible
The transfer-path section is the design. The FIPS section explains a distinction that costs points on the score. The last section is the honest list of what you can fix with configuration rather than a project.
What the requirements actually ask of these two systems
The one hundred and ten requirements do not have an email chapter. They have families that mail and file sharing touch from several directions at once, and four of those touches carry unusual weight.
Cryptography has to be validated, not merely present. The requirement covering cryptographic protection of CUI (SC.L2-3.13.11) is one of only two requirements in the scoring model with partial credit built in: using encryption that is not FIPS-validated loses fewer points than using none, but it still loses points. That distinction is the most misunderstood item in this whole area, and it has its own section below.
Multifactor authentication is the other partial-credit requirement. IA.L2-3.5.3 loses points if multifactor is implemented only for remote and privileged users rather than across the board. Mail is usually the first place a company turns it on and the last place it gets turned on for everybody, because of a service account, a scanner, or a legacy client somebody is afraid to break.
Two access-control requirements can never sit on a plan of action. AC.L2-3.1.20, covering external systems and connections, and AC.L2-3.1.22, covering control of information posted or processed on publicly accessible systems, are two of the six requirements that are ineligible for a plan of action at any score. Both land squarely on file sharing. An anonymous share link is, functionally, publication. Check these two before you plan anything else.
Marking, handling and destruction come from the media family. CUI in a mailbox or a document library is CUI in storage. The obligations to mark it, control access to it, and dispose of it properly do not soften because the medium is a mailbox rather than a filing cabinet.
FIPS-validated is a specific thing, and turning it on is a separate step
Almost every product you use encrypts data. Far fewer use a cryptographic module that has been validated under the government's Cryptographic Module Validation Program, and of those, a good number ship with the validated mode switched off by default. Validation is a certificate held by a specific module version, and the certificate names what was tested. It is not a property of the marketing phrase “bank-grade encryption.”
Three practical consequences follow. Ask the vendor for the certificate number rather than for an assurance. Confirm whether the validated mode requires configuration, because a product that is capable of FIPS-validated operation and is not operating that way does not satisfy the requirement. And check the certificate's current status, because validations move through lifecycle states and a module can be listed as historical while the product is still shipping.
The cloud side has its own version of this. The DFARS safeguarding clause requires that a cloud service used to store, process or transmit covered defense information meet security requirements equivalent to the FedRAMP Moderate baseline. The Department has issued guidance on what equivalency demands, and the direction of that guidance has been toward a documented body of evidence assessed against the Moderate baseline by an independent assessor, together with a customer responsibility matrix telling you which controls are yours. Read the current memorandum rather than a summary of it, and ask the provider for the artifacts by name.
Then check the FedRAMP Marketplace listing yourself. Provider names and service names are not the same thing, and a vendor that is authorized for one offering is regularly assumed to be authorized for a neighboring one. The listing tells you the offering name, the impact level, the status, and the boundary. Two minutes on that page has saved a lot of firms from a much longer conversation.
The design that holds: one sanctioned path, instrumented
The workable pattern is a small assessed environment where controlled work happens, plus exactly one supported way in and one supported way out. Everything else in the company stays clear of CUI by design, gets documented as risk-managed, and stays out of the expensive assessment category.
Inbound. A single place external parties send controlled material — a portal inside the boundary, a monitored drop, or a government system you pull from. The address must be published, the workflow must be one step, and a person must own the queue. If receiving a file requires four emails and a password over the phone, the customer will attach it to a normal message instead and mean well while doing it.
Outbound. One approved mechanism for sending controlled material out, with a record of what left, when, and to whom. That record is not bureaucracy; it is the generated evidence that makes several assessment objectives easy, and it is the first thing you will want during an incident.
General mail stays outside. If ordinary corporate email never carries CUI, it can be documented as an asset kept clear rather than assessed against the full set. Making that claim credible needs three things: a real alternative path, technical prevention rather than an instruction, and a way to detect the leak when it happens anyway. All three, or the claim will not survive an interview.
Detection over prohibition. Content inspection, marking-based rules, and alerting on outbound attachments give you a mechanism instead of a hope. They also produce the records that show a control operating over time, which is the class of evidence most packages are short of.
| Channel | What usually goes wrong | The design that holds |
|---|---|---|
| Inbound email from a customer | An engineer attaches a drawing because it is faster than the portal | A published, one-step inbound path with a named owner, plus detection on the mailbox that catches the exceptions |
| Outbound deliverables | Sent from whatever tool the author had open, with no record | One approved mechanism inside the boundary that logs sender, recipient, artifact and time |
| Internal file sharing | Anonymous links, org-wide permissions, inherited access nobody reviews | Anonymous links disabled at tenant level; access by group; a periodic review that produces a dated record |
| External collaboration | Guest accounts created ad hoc and never removed | Guests only in a designated area, expiring by default, reviewed on a fixed cadence |
| Sync clients and personal devices | A library syncs to a home laptop nobody manages | Sync restricted to managed devices; conditional access on device state; no local copies from the enclave |
| Mobile mail | Mail on personal phones with no separation | Managed profile with separation and remote wipe, or no controlled mail on mobile at all — decided explicitly, not by default |
| Third-party integrations | Note-takers, transcription and automation tools reading the mailbox | An approved list, reviewed; consent restricted; every integration named in the system security plan |
Where the sharing side actually leaks
File sharing platforms are built to make sharing easy, and their defaults reflect that. The leaks are rarely exotic.
Link scope. The difference between a link that works for anyone who has it and one that works only for named people is one dropdown, chosen under time pressure by someone helping a colleague. Set the tenant default to the restrictive option and let people widen it deliberately, rather than the reverse.
Inherited permissions. Access granted to a folder in 2023 quietly covers everything added since. Periodic access review is a requirement in its own right and the record it produces is worth more than the review itself.
Guest accounts that outlive the project. Every collaboration platform accumulates these. Expiry by default converts an ongoing governance chore into a one-time configuration.
Sync to unmanaged endpoints. The library is inside your boundary and the laptop is not. This is the single most common way controlled files reach a machine that no assessment covers.
Search and preview surfaces. A document's content is often reachable through search, previews, and connected assistants even when direct permissions look tight. Test what a low-privilege account can actually retrieve, rather than reading the permission model and assuming it holds.
Where we find controlled data outside the boundary — our read
Our judgment from doing this work, not a survey. The bottom row is the newest and the least often asked about.
The tenant question, answered honestly
Sooner or later someone tells a defense supplier it needs a government community tenant. Sometimes that is right and sometimes it is an expensive reflex, and the way to tell is to stop asking which tenant and start asking three separate questions.
What does the offering actually hold? Look up the specific service offering on the FedRAMP Marketplace — not the vendor family, the offering — and read its impact level, status and boundary. Then ask the vendor for the equivalency artifacts the safeguarding clause implies, in writing.
Where does the data live and who can touch it? Data residency and the citizenship or screening status of support personnel are separate commitments from an authorization, and they are the reason many firms end up in a government community offering regardless of the authorization question.
Is export control in play? If any of your controlled data is export-controlled, its handling obligations come from the export rules and exist whether or not a defense contract is involved. That is frequently the actual driver of the tenant decision, and it is a legal question worth answering before a procurement question.
Answer those three and the tenant decision usually makes itself. Answer none of them and you may buy a more expensive product that solves a problem you did not have while leaving the one you did have untouched.
What you can fix this month, without us
A meaningful share of the leak in a typical company closes with configuration, and it is worth saying so plainly.
Turn off anonymous sharing links at the tenant level. Set external sharing to named recipients only. Put expiry on guest accounts. Require multifactor for everyone rather than for remote users only, and find out what breaks. Restrict sync to managed devices. Review connected applications with mailbox access and remove the ones nobody can justify. Turn on the audit log and set retention deliberately. Publish the inbound path and tell your customers about it. None of that is an engineering project. It is a careful week by someone who knows the platform, and it moves both the score and the actual risk.
Where outside help is worth paying for is narrower: designing the enclave and its transfer points so people use them, building the detection and the evidence generation, and getting the answers from providers whose responsibility matrices are not on their website. If your environment is one identity provider, one tenant, managed endpoints and a capable administrator, most of this article is a configuration checklist rather than a statement of work.
The mistakes we see most
- A policy against CUI in email with no alternative path — which people follow until the first deadline
- Assuming encryption is FIPS-validated because the vendor page says the data is encrypted
- Buying a government tenant first and never asking what the offering actually holds
- Leaving anonymous links enabled, against a requirement that can never sit on a plan of action
- Multifactor for remote users only, losing points on one of the two partial-credit requirements
- Sync clients on unmanaged laptops, quietly extending the boundary to machines nobody assesses
- Guest accounts with no expiry, reviewed the week before an assessment and never again
- No record of what left the boundary, so both the evidence and the incident response start from nothing
Before you call this area done
- There is exactly one published inbound path and one outbound mechanism
- Both are faster than the workaround, and the people who use them agree
- Anonymous and org-wide sharing links are disabled at tenant level
- Guests are confined to a designated area and expire by default
- Sync is restricted to managed devices with conditional access on device state
- Multifactor covers everyone, and the exceptions are named and justified
- Cryptographic modules are FIPS-validated and the validated mode is switched on
- Cloud providers have supplied equivalency artifacts and a responsibility matrix
- Detection exists for controlled content leaving through ordinary mail
- Audit logging is on, retained deliberately, and produces a dated record you can hand over
Bottom line
Mail and file sharing are where compliance meets the way people actually work, and the side that wins is whichever one is faster. Build a single sanctioned path in and out of a small assessed environment, make it genuinely easier than the workaround, and instrument it so that using it produces the evidence you will need anyway. Verify FIPS validation with a certificate number rather than a claim, verify cloud equivalency against the Marketplace listing and the provider's own artifacts, and fix the sharing defaults this month because they are free and they sit on requirements that cannot be deferred. Do that and this area stops being the thing that undoes everything else.
Frequently asked questions
The requirements do not name email. They require that CUI be protected in transit with validated cryptography, that access be limited to authorized people, and that the systems holding it sit inside a defined boundary. An email system that meets those conditions can carry CUI; ordinary corporate mail with opportunistic transport encryption and no boundary claim generally does not. Most firms find it cheaper to keep controlled material out of mail entirely and give people a portal, because that keeps the mail platform out of the assessed category.
Not on its own. The cryptography has to be FIPS-validated, the key or password has to reach the recipient by a channel that is itself protected, and the copy sitting in the sender's mailbox is still a copy inside whatever boundary that mailbox belongs to. Password-protected archives sent through general mail also produce no record of what left, which is the evidence you most want later.
Not automatically. The clause requires a cloud service to meet security requirements equivalent to the FedRAMP Moderate baseline, and it does not name a product. What usually drives firms toward a government community offering is a combination of data residency, screening of support personnel, and export-control obligations that exist independently. Check the specific offering on the FedRAMP Marketplace, ask for the equivalency artifacts in writing, and settle the export-control question before the procurement question.
By making the claim true and then evidencing it. That means an alternative path people actually use, technical prevention rather than an instruction, detection that finds the exceptions, and a documented procedure with a named owner. Under the scoping rules, a system kept clear of CUI by policy and procedure is documented and risk-managed rather than assessed against the full set — but an assessor may still look at it if the system security plan raises a question, and interviews are where a paper claim comes apart.
Each one is an external service provider that reads content, and each needs a written answer about what it stores, where, for how long, and whether it is used to improve a model. Review the connected applications in your tenant, restrict who can grant consent, remove what nobody can justify, and name the survivors in the system security plan. This is the fastest-growing gap we find and the one least often asked about.