Govern Your Data Before You Have Any
Building a fit-for-purpose data governance regime
While much of Factory Settings has been about the challenges of starting a government program from scratch, a clean slate also has its benefits. One domain in which starting fresh was a luxury was data governance.
As a once-in-a-generation bet, CHIPS depended on quickly demonstrating competency and building up trust with industry. We were working with some of the most advanced industrial projects on the planet, and our work would need to collect and integrate information that companies in this field guard very carefully, including technology roadmaps, financial models, and where and when they planned to build.
Our team knew we would need data to inform our investment decisions and to manage the program’s risk. We also knew we needed a robust approach to protecting and managing this data. Companies needed to trust that the information they gave to us would be protected. This piece details how we approached this challenge.
The data governance of government data
Like any large-scale organization, the government collects and stores vast amounts of data. How those data are used, managed, and governed varies dramatically based on the program context.
You can imagine that for some programs, where data is the lifeblood of the work (such as the Census Bureau or the Bureau of Labor Statistics), there would likely be a great deal of attention paid to robust data management and governance practices. But in my experience that’s the exception, and instead many government programs that rely on data for analysis and decision making nonetheless have to work around their data — meaning they create processes and analysis based on the system architecture and data integrity constraints that already exist. Because of this, even a new appropriation for a new grant program, regardless of whether it has the opportunity to collect new data, is largely constrained by the extant data collection systems, legacy access controls and policy, and, in some cases, the Paperwork Reduction Act approvals already in place. As a result, data governance in government programs often looks akin to a neglected attic or basement — a heap of legacy, redundant boxes (datasets embedded in old systems) with known shortcomings that federal employees nonetheless use, trekking up into the attic to sift around and file new data, always finding ways to work around the obstacles in service of their mission. None of this is surprising. Federal agencies report spending roughly 80% of their IT budgets just running and maintaining the systems they already have — which is another way of saying that most programs operating since forms were paper never had the money or operational room to systematically modernize.
Data governance as a named federal imperative barely predates CHIPS: it became a government-wide mandate only with the Evidence Act of 2018, which for the first time required agencies to appoint chief data officers and stand up data governance bodies.1 For CHIPS, we were essentially starting fresh: we would be working with new grantees who might never have done business with the government before, a new system, and entirely new staff.
Data governance has multiple dimensions.2 For CHIPS, as would likely be the case for any new industrial policy program, we were focused first and foremost on data protection. Both the CHIPS Act and the Trade Secrets Act had strong information confidentiality provisions, which made sense.3 Companies submitting technology roadmaps, workforce projections, and financial structures to a new program reasonably wanted guarantees that those submissions wouldn’t end up anywhere they shouldn’t. Any significant breach would be a threat to our credibility and an existential risk to CHIPS as a whole.
Program leadership came in with a strong understanding of the importance of data governance. Mike Schmidt had run the state tax agency in New York; Todd Fisher had previously worked in private equity, which has strict confidentiality standards; and I had significant experience with many forms of government data, including data governance programs for student data, which has special protections under the law.
Our team understood data governance to be both a technical and a personnel challenge. To meet the challenge, we worked closely with our IT team to implement rigorous technical controls. We also established principles that shaped how the team functioned in the service of data governance. One initial technical aspect of building a data governance program — first and foremost figuring out exactly which data can and should be stored where — is more important than most people realize: it has implications for data security, your day-to-day operations, and the integrity of your analyses and conclusions. It is also significantly easier to manage if you think through your goals and build a system around those goals before you have any data to manage. If you are afforded this luxury of preplanning, do not waste the opportunity.
The CHIPS data strategy
As a new program, CHIPS would be collecting information into a new system and would represent the first time the National Institute of Standards and Technology had collected information from most of these specific applicants. Because the program was new, we also had precise control of the types of data that would be collected, no prior definitions or systems to work around or be backward-compatible with, and maximum ability to shape exactly how those data were managed. We could design our data governance rules from the start.
Our ability to proactively decide what to collect proved valuable. Once we published the Notice of Funding Opportunity (or NOFO, as it was known) and potential applicants saw what information they’d need to submit, they wanted assurance about how we’d protect their information from both leaks and competitors. In response, we published a statement explaining the laws protecting confidential information.
But the bigger lift was developing specific data handling procedures. Before we had a single application in hand, we thought through the full range of questions that prospective applicants might have: what data we were collecting, how it was categorized, who could access what, under what conditions, and what the consequences of misuse would be. The technical implementation, access controls, and training we designed all flowed from that.
Our data governance approach was grounded in three key design decisions:
Building a comprehensive data inventory, categorized by sensitivity at a granular level;
Instituting the principle of least access; and
Signaling from leadership that data protection was everyone’s responsibility.
We categorized all data by sensitivity level
At the core of our strategy was a central data inventory, for which we could build fit-for-purpose rules to manage data storage, transmission, and access. To design the inventory, we cataloged all the types of data we would ask applicants to submit — technology information, financial projections, workforce plans, construction plans, and so on — so that we could categorize the substantive content applicants would be providing, as well as any derivative work product our analysts would generate from it.
Each data type was categorized with a sensitivity label, and that designation then drove the rules about how and where the information could be stored and how it could be transmitted. For example, for certain levels of sensitivity, electronic transmission was not allowed — you literally had to deliver a paper copy. We also distinguished between aggregate or de-identified information, which carried less stringent rules, and applicant-specific information, which had the most stringent protections.4
We instituted the principle of least access
We followed the principle of least access, giving users only the access privileges that they needed to perform their roles, and no more. In our systems, access was therefore organized into three tiers:
“Enterprise access” was given only to staff whose jobs required visibility across the full applicant pool — this included program leadership, legal, and risk.
“Applicant access” went to staff assigned to specific applicants; those team members could see everything about the companies they were assigned to but not data about any other ones.
“Content access” was narrower still: if your job was environmental review, you could see every applicant’s environmental submissions and nothing else.
Getting any tier of access required a written justification, which had to be reviewed and approved by me and our chief counsel. These decisions were recorded and audited weekly against actual system access; every week, we’d pull the records of approved access requests and the records of who actually had access to make sure they were 100% in sync.
This permissions architecture also came with a non-redisclosure requirement: even if you were granted access to applicant information, you were nonetheless explicitly prohibited from sharing that applicant information further (with anyone, including within the program) without express authorization from program leadership.
On the technical side, we worked with our IT team to build a folder infrastructure in our shared network that matched these access tiers. Applications routed automatically from the intake portal into the correct folders so there was no need for manual downloading or risk of accidental access. We layered in automated data loss prevention controls on top of this: every document was automatically tagged with its sensitivity designation, and attempts to transmit a tagged document outside approved channels were blocked. Both the sender and I would be notified about such attempts, and I would then step in to investigate the incident. This ensured that when people made a mistake, we knew about it, they corrected it, and it didn’t happen again.
Another key design decision we made was not to use company names. From day one, applicants were assigned codes and referred to using those codes in most internal contexts, whether that be in documents, folders, or meetings. This gave an added layer of protection — even if a document was leaked to someone or someone overheard a hallway conversation, they couldn’t immediately identify the specific company being discussed.
We made the stakes explicit to all staff members
Before anyone on the team received data access, they had to sign a data use acknowledgment and complete training. We used this training to walk through our data policy in detail and had a member of our chief counsel’s office explain its statutory underpinnings. Rather than being merely a superficial compliance exercise, the training provided real instruction on what the Trade Secrets Act covers, what the CHIPS Act’s confidentiality provisions require, and the consequences of mishandling. The goal was to drive home the importance of the data governance architecture and rationalize some of the friction it created day to day.
The language in the data use acknowledgment form was explicit: it made clear that the data included information protected under the CHIPS Act and the Trade Secrets Act, and that unauthorized disclosure carried serious consequences including removal from federal service. Anyone who signed it affirmed that they had read the policy, agreed to abide by its provisions, and understood the consequences of failing to do so.
Data architecture shaped behavior across agencies
Federal programs don’t operate in a vacuum. Officials both within our own agency and at other agencies often have legitimate vested interest in how a major program is doing. One unexpected (but welcome) side effect of our stringent data practices was that our rules governed not just our own team’s behavior, but also let us set clear and unapologetic boundaries for those outside of the program who were interested in our progress.
A documented and consistently applied access policy made it easy to field those requests: while there were of course appropriate and strategic reasons to share details in some cases, as a general matter, we would share only aggregated information when briefing officials. Referring to our information security policies spared us from case-by-case explanations for why we were declining to share information someone might otherwise feel entitled to.
I’m not suggesting any of the officials we spoke to were asking for anything improper. But well-intentioned people make mistakes; anyone outside the CHIPS Program Office who hadn’t been beaten over the head about the finer points of our data policy and shared what they’d learned in a briefing could compromise the whole system. The policy protected them as much as it protected us. It also meant we were being consistent, which matters a lot for a program under constant scrutiny.
Data governance comes with friction
I stand behind our approach to data governance, but it’s important to acknowledge that in practice, it was clunky — and the team could get really frustrated with it. Everyone understood the importance of the controls we implemented, but the procedures built into getting approvals occasionally took too long; when you are under pressure to get something done, waiting to get access to a shared folder is frustrating. Figuring out how to analyze a particular deck or what the permitted transmission modes were for a document based on the data in it could slow things down.
In hindsight, we made some mistakes designing the first version of our system. For one, the folder structure was overwrought. This was somewhat inevitable — while we knew what data elements companies would be submitting, we couldn’t predict exactly how many applications across how many projects we would receive, nor could we anticipate exactly how we’d want to manage multiple applications from a single applicant, or how we’d handle some kinds of data on a day-to-day basis. So fully locking ourselves into a folder architecture and automated ingestion before we knew exactly what our full workflow would be created some headaches down the road.
At our first all-staff meeting, data access complaints were among the handful of grievances. Our data team made real efforts to address them, but because of some of the early architectural decisions about folder structure and access tiers, there was only so much we could do without fully disrupting everyone’s work. Understandably, the grousing never fully subsided.
Being the architect of this policy made me a bit unpopular, but I was glad to take the hit. Next time around, I would see if we could get more precise on the workflows for folks using the data earlier, and try to incorporate more flexibility to account for unknowns.
Our approach to data governance ultimately did what we needed it to: we did not have any serious technical or accidental breaches. But we did have leaks.
On several occasions, right when we were getting close to a breakthrough in a negotiation that could result in a deal, one news outlet in particular — one reporter in particular — would get the scoop. While the reports occasionally got some details wrong, they were close enough too often for our comfort. Those leaks kicked up a lot of internal drama — people wondered who the culprit was and why we couldn’t stop them. Companies were pissed.
We considered all sorts of tactics to ferret out the leaks, but none of them felt appropriate or aligned with who Mike Schmidt and I were as leaders. So as much as I’m convinced that our work on data governance was well worth the effort, it’s also clear to me that even the perfect data governance ruleset can’t protect against someone crossing the line.
Don’t let data be an afterthought
If you are standing up a program that will collect sensitive information — and most serious industrial policy programs will — build a flexible data governance architecture before applications arrive. The Paperwork Reduction Act will likely still constrain what you can ask for and how you ask for it, but if you don’t design your systems before the data come in, you’re left to govern retroactively, which is guaranteed to be a mess.
Spend time on policy development, accounting for both the statutory guardrails and industry expectations, and carefully consider who needs access. Then build a system to support the policy, ideally building in the ability to flex when you get thrown the inevitable curveball. And put someone in charge of this work, someone who can seek to balance the goal of maximum security with the aim of minimal burden and inefficiency, and who won’t mind terribly if people think they leaned too heavily in favor of the former. And of course build culture alongside the architecture, and think in advance about what you’ll do if information leaks.
If you don’t have good data governance, having a well-run program will be that much harder.
Pub. L. No. 115-435, the Evidence Act, was signed January 14, 2019, and contains a requirement for chief data officers at 44 U.S.C. § 3520.
The Federal Data Strategy’s Data Governance Playbook defines data governance as “the process of setting and enforcing priorities for managing and using data as a strategic asset,” and identifies data management policy as a key activity of data governance — one that includes developing rules for governing the creation, acquisition, privacy, integrity, security, quality, and use of data and information.
The CHIPS Act exempts information disclosed by covered entities from FOIA and provides that it ‘shall not be made public’. Furthermore, the Trade Secrets Act makes federal employees criminally liable for unauthorized disclosure of information that “concerns or relates to the trade secrets, processes, operations, style of work, or apparatus, or to the identity, confidential statistical data, amount or source of any income, profits, losses, or expenditures of any person, firm, partnership, corporation, or association.” Penalties include loss of employment, fines, or imprisonment.
While such categorization is technically required of all federal programs by the Federal Information Security Modernization Act, in my experience it is generally done at a system level, and I’m not sure I ever heard sensitivity levels discussed as a day-to-day matter of program operations. CHIPS took the unusual step of doing this categorization at a more granular level, and categorizing several components of the data we were collecting at higher levels than other grant programs would, and using these rules to shape our daily operations.