A board needs six facts about customer login, in plain language: who can sign in and how that is controlled, how a former employee or former customer user loses access, how sign-in is protected beyond a password, who runs the login system and what happens if that person leaves, what happens if login goes down and how long recovery takes, and what the system costs now and as you grow. If you can answer those six on one page, with an owner and a date next to every gap, you have given the board what it actually needs to oversee the risk.
This post is for the engineer or head of platform who has been asked for a security update for the board or investors, and for the CTO or founder who will present it. It explains what the board is really asking, what to say for each of the six facts, how to report gaps without alarming people, and it ends with a one-page template you can copy. It assumes a B2B SaaS, education technology or non-profit platform with roughly 20 to 300 people, where customer accounts are the thing most worth protecting.
Why do boards ask about login, and what are they really asking?
They are asking whether a stranger could get into a customer’s account, and whether you would find out and recover if it happened. Customer login is the control in front of most customer-facing access, so questions about account security usually come back to it. The trigger is usually outside your company: an investor reads about a breach at another business, a funder adds a security question to a renewal, or a large customer includes one in a review.
Boards also have a formal reason to care. In the United States, public companies must describe their board’s oversight of cybersecurity risk in annual reports under rules the Securities and Exchange Commission adopted in 2023 (SEC press release 2023-139), and the U.S. National Institute of Standards and Technology added a “Govern” function to its Cybersecurity Framework in version 2.0 in 2024 to describe the leadership side of the same job (NIST Cybersecurity Framework). A private company is not bound by the SEC rules, but investors and large customers often use the same vocabulary.
What questions come from investors, funders and large customers?
The wording differs, but the questions are close to the same set. Investors often ask about the likelihood and cost of a breach. Funders and public-sector customers often ask about who has access and how it is reviewed. Large customers often send a questionnaire, and the security questionnaire post shows what those usually ask about login. Preparing one set of answers for the board also gives you most of what you need for the others.
What facts should a board be told, in plain terms?
The six below are enough for a one-page update. For each, state the current position in one or two sentences, avoid product names and protocol acronyms where a plain word works, and say how you know (a setting, a report, a test).
Who can sign in to the product, and how is that controlled?
Say who has accounts (customer users, customer administrators, your own staff), how an account is created, and whether sign-in is handled by a dedicated identity system or by code inside the product. The board does not need the technology, only the answer to “is there one place where we control who gets in?” If the answer is “partly”, say which parts.
How does a former employee or former customer user lose access?
This is the question that exposes the most gaps. Explain how access is removed when someone leaves your company, when a customer’s employee leaves the customer, and when a customer ends its contract. Say whether removal is automatic (for example through a link to the customer’s own directory) or depends on someone remembering. The user access review guide explains the periodic check that catches what automatic removal misses.
How is sign-in protected beyond a password?
Say whether multi-factor authentication (a second proof of identity, such as a code from an app, or a phishing-resistant method such as a passkey) is available, required for staff and administrators, and offered or required for customers. A useful number for a board is the percentage of administrator accounts that have it enabled, since administrators are the accounts attackers want most. Say plainly if it is optional for ordinary users.
Who runs the login system, and what happens if that person leaves?
Name the team or person who maintains it, and say whether anyone else could take over within a few days. This is a continuity question rather than a technical one, and it is usually easy for a board to follow. If the system is run by a vendor, say who at your company owns the relationship and reviews the vendor’s reports.
What happens if login goes down, and how long does recovery take?
When login is down, customers cannot use the product at all, even though the rest of it is healthy, so the board should know your expected recovery time and who decides what to tell customers. The identity resilience post describes what typically fails first and which design choices reduce the impact. If you have never tested recovery, say so and treat that as a gap to schedule.
What does the login system cost now, and how does that change as you grow?
Give the current annual cost and say what it depends on: the number of active users, the number of customers, or a fixed plan. Boards care about this because a cost that grows with users can change your margins as you succeed. Give one sentence on what you expect it to be in twelve months, and where the estimate is uncertain, say so.
How do you report gaps without alarming people?
State each gap as a fact with an owner and a date, in the same tone as the rest of the page. Boards react badly to surprises and to vagueness, and much less to a gap that already has a plan. A gap you name yourself shows the board that your process catches problems, whereas a gap the board finds later makes them doubt the rest of the page.
How do you name a gap, an owner and a date?
Use the same three parts every time: what is not yet true, who is responsible for closing it, and by when. For example: “Multi-factor authentication is optional for customer users. The product lead owns making it available by default. Target: end of next quarter.” Avoid hedges like “we are looking into” because they sound like there is no owner. If a gap has no funding yet, say that, since it is a legitimate request for the board to act on.
What does a one-page template look like?
Copy this structure and fill each line with a sentence or two. Keep it to one page so it gets read, and keep the evidence in a separate folder instead of attaching it.
| Section | What to write | Status | Owner and date |
|---|---|---|---|
| Who can sign in | Account types and where control sits | Meets / Gap | |
| Removing access | How leavers lose access, and how often it is checked | Meets / Gap | |
| Sign-in protection | Where multi-factor is required, offered or absent | Meets / Gap | |
| Who runs it | Team or vendor, and the backup if they leave | Meets / Gap | |
| Outage recovery | Expected recovery time, last test date | Meets / Gap | |
| Cost | Current annual cost and what it depends on | Note |
Below the table, add three short lines: the one change you most want the board to know about, the one decision you need from the board (if any), and the date of the next update. Our for leaders page is written for the same non-technical readers and may help with wording, and the vendor risk brief covers the related job of assessing a vendor, which this update does not replace. If you are weighing a change of provider, that belongs in a decision memo rather than in the board update.
If your login system is provided by Skycloak, our trust page and security page list what we document about our own controls, which you can reference as evidence behind the page.
Frequently asked questions
How often should the board hear about customer login risk?
Once or twice a year is enough for a stable situation, and after any significant change such as a new provider, an incident, or a large customer requirement. A short standing line in the regular security update works better than a separate annual presentation.
What evidence should sit behind the page?
Keep a folder with the screenshots or reports that back each line: the multi-factor setting for administrators, the last access review, the last recovery test, and the current contract or invoice for the login system. You do not need to show them to the board, but you should be able to produce them within a day if someone asks.
Who should present it?
Usually the CTO or founder presents it, with the engineer or head of platform available for questions. The engineer writes the first draft because they know the facts, and the presenter edits it for the board’s level so nobody has to translate in the meeting.
Should we include statistics about breaches?
Only if you can link the source and it applies to your situation. A board update is stronger when it describes your own controls and gaps than when it quotes industry numbers, and an unsourced figure undermines the rest of the page.