How to write client account handling into your agency's security policy

An agency that runs clients’ social, ad and store accounts can put its account rules into three documents, each for a different reader. The three are a short security policy anyone can read, an internal policy your staff follow, and an access summary you give each client. A questionnaire answer or a contract clause about accounts can then be copied from one of the three.

Why three documents

The NIST Small Business Quick-Start Guide for the Cybersecurity Framework (CSF) 2.0, NIST SP 1300, asks small firms to “Communicate, enforce, and maintain policies” that address cybersecurity risk (GV.PO-01). The same guide asks them to assess risks from suppliers before entering formal relationships (GV.SC-06). A client that follows it may look at your policy before it signs with you.

Your clients may also have a legal reason to check. Under the California Consumer Privacy Act (CCPA), a business that hands consumers’ personal information to a service provider must sign an agreement with it (Cal. Civ. Code 1798.100(d)). A “business” here is a for-profit company doing business in California that meets a threshold, such as annual gross revenue over $25 million, adjusted for inflation (1798.140(d)). The agreement must let the business take reasonable and appropriate steps to help make sure the provider uses the data the way the CCPA requires. If you agree, the contract may also let the client monitor you, including assessments or audits at least once every 12 months (1798.140(ag)(1)).

But the details of account handling don’t belong on a public page. A list of who can reach which client account, and how you check who signs in, is more useful to an attacker than to a prospect. Keep the rules in the internal policy, and give each client only its own accounts in its access summary.

What the public policy says

Keep it short. Say that the policy covers information and accounts clients entrust to you, not only your own systems. Say that access is limited to the people who need it for the work, which matches CISA’s Cyber Essentials advice to grant access on “need-to-know and least privilege”. Name a contact for security questions. Leave out platform names and staff counts.

Rewriting template rules for client logins

The CSF 2.0 outcome PR.AA-01 is written for accounts you control: identities and credentials “are managed by the organization”. A policy rule built on it, such as deleting a person’s account when they leave, assumes you can do that yourself. A client’s ad or social account is managed by the client. Four rules need rewriting for it.

One person, one login

Cyber Essentials tells you to use unique passwords for all user accounts. Where a platform lets the client invite each of your staff by name, that’s delegated access. Some platforms don’t offer it, and some tasks need the owner’s login. So write the rule in two parts. Use delegated access wherever the platform offers it. Allow a shared client login only when it doesn’t. Then keep a list of the staff allowed to use each one, and a record of who used it and when. Before taking on a shared login, check whether the platform’s terms forbid sharing.

Removing access that is no longer needed

SP 1300 asks whether you are “removing access when they no longer need it”. With a client login, you often can’t do that alone. Removing a person from some platforms takes the client’s admin, and a shared password stays known until the client changes it. So write down your own step and its deadline: stop the person’s use and send the client the request. Then record the day the client finished its part.

Departures and role changes

Cyber Essentials asks for policies and procedures that address changes in user status, such as transfers or terminations. A person leaving can’t hand back a password they remember. So the offboarding checklist lists every client account the person could use. Next to each one, it names the step for that kind of access. Remove the person from the platform, ask the client for a new password, or remove them in your access tool. Use the same list when someone rotates off a client without leaving. The full checklist is in Account handover checklist when agency staff leave or change roles.

People outside your staff

To your client, a freelancer you bring into its accounts is your subcontractor. Under the CCPA, a service provider that brings in another person to help process personal information it handles for the client must notify the client of that engagement. It must also bind that person by written contract to the same terms (1798.140(ag)(2)). So the rule needs more than a confidentiality agreement. It also needs a step for telling the client. The CCPA sets no deadline, so the simplest rule is to tell the client before the freelancer starts.

What the client access summary says

The access summary applies your internal policy and your contract to one client’s accounts. For each account, it gives five things.

1. The platform, the account name, and how you get in: delegated access, a shared login, or an access tool. The method decides what records exist and what a staff change takes.
2. Who can use it. For a shared login, also who knows the password, because the platform can’t show you that.
3. How use is recorded: the platform’s history or your own work log. This decides what you can show after a mistaken post or a wrong setting.
4. What happens when staff change and when the contract ends: your steps, the client’s steps, and the deadline for each. A missed client step leaves a former staff member able to sign in.
5. Who to contact if either side suspects misuse.

Name the internal policy section behind each line, so the client can trace it when it checks. CSF 2.0 asks for policy to be reviewed and updated as requirements change (GV.PO-02). Update the summary when staff on the account change or the access method changes, and date each revision.

This article is not legal advice. Have your lawyer review the wording of your policies and summaries.