IT And Cybersecurity Compliance

The Compliance Map

The Compliance Map is a practical way to connect requirements to the systems, people, and evidence in your business. Start with the information you handle, then identify the rules that protect it. Next, connect each rule to a control, assign an owner, and save proof that the control operates.

Use these five parts:

1. Information - List the data your business creates, receives, stores, or sends. Examples include payment details, employee records, health information, customer addresses, and login credentials. You need this list because you cannot protect or audit information that you have not identified.

2. Requirement - Record the source of each obligation. A requirement may come from a privacy law, a payment-card contract, a customer agreement, or an internal policy. Write the exact requirement in plain language, such as “Remove access when employment ends” or “Protect stored customer records from unauthorized access.”

3. Control - Choose the action or safeguard that meets the requirement. For account removal, the control might require the office manager to submit an access-removal request on the employee’s final day. For stored records, the control might require encryption, which changes readable data into protected code that needs a key to open.

4. Owner - Name the person responsible for performing and checking the control. “The technology team” is too vague for an audit. Use a role or person, such as “Office manager submits the request; system administrator confirms removal.” Clear ownership prevents important tasks from disappearing between departments.

5. Evidence - Save proof that the control happened. Examples include an access-removal ticket, a monthly user review, an update report, or a backup restoration test. Evidence matters because an auditor cannot rely only on verbal claims.

A simple table makes the map usable:

| Information | Requirement | Control | Owner | Evidence | |---|---|---|---|---| | Customer invoices | Limit access to approved staff | Review accounting permissions monthly | Accounting manager | Signed review and system export | | Employee records | Remove access when employment ends | Submit and confirm an offboarding ticket | Office manager and system administrator | Completed ticket | | Business files | Recover files after accidental deletion | Run nightly backups and test one file monthly | System administrator | Backup report and test result |

The Compliance Map also changes how you approve technology. Before buying a cloud application, ask what information it will hold, which users need access, how the provider protects the information, and whether the provider supplies useful records. Before granting an employee administrator access, ask why ordinary access will not work and set a review date. Before deleting a system, confirm whether it contains records that the business must retain.

Keep compliance separate from security marketing. A vendor may say that a product is “secure,” but that statement does not prove that the product meets your specific requirement. Request practical details: available access logs, multi-factor authentication, backup settings, data location, breach-notification terms, and audit reports when relevant. Multi-factor authentication requires two or more forms of proof, such as a password and a code from a phone. It reduces the damage from a stolen password, but it does not replace account reviews or timely offboarding.

Review your map whenever you add a system, change a process, hire or lose staff, receive a new customer contract, or discover an incident. A small business may start with a spreadsheet and a shared folder with restricted access. The tool matters less than keeping the entries current and linking each requirement to an action and proof. The practical takeaway: every compliance requirement should answer five questions - what information, which rule, what control, who owns it, and what evidence proves it?

Applying the Compliance Map to a New Customer Portal

A repair company plans to launch an online customer portal on October 1. The portal will store names, addresses, service history, invoices, and payment information handled by a separate payment provider. The company has six office employees, two technicians, and one system administrator. The owner wants the portal ready without creating an audit problem.

1. List the information before selecting settings. The team records each data type and marks payment information as handled by the payment provider. Expected outcome: the team knows which records belong in the portal and which records should never enter it.

2. Read the customer contract and provider terms. The contract requires restricted access, prompt removal of former users, security incident notices, and records showing access reviews. The team copies these requirements into the map. Expected outcome: the company can point to the exact source of each obligation instead of relying on memory.

3. Create roles with the least access needed. The office manager receives permission to view invoices and customer contact details. Technicians receive service-history access but cannot export all customer records. The system administrator receives technical administration access and uses a separate administrator account. Expected outcome: each person can perform assigned work without receiving unnecessary data.

4. Turn on protective settings. The administrator enables multi-factor authentication for all staff, automatic updates, session lock after 15 minutes, and logging for sign-ins and record exports. The team tests each setting with a test account before launch. Expected outcome: the portal records important activity and reduces exposure from stolen passwords or unattended computers.

5. Assign daily and monthly responsibilities. The office manager sends an access-removal request when a worker leaves. The administrator confirms removal the same day and saves the ticket. On the first business day of each month, the owner reviews the user list and signs the review record. Expected outcome: the company can show both timely offboarding and regular access checks.

6. Prepare evidence before anyone asks for it. The administrator creates a restricted compliance folder containing the signed map, provider agreement, role list, authentication settings, monthly review records, update reports, and a test incident record. Expected outcome: an auditor can trace requirements to controls and controls to proof.

7. Test the process on September 25. The owner asks the office manager to remove a test user, the administrator confirms removal, and the team checks that the event appears in the log. They also restore one sample invoice from backup. Expected outcome: the company finds gaps before launch instead of during an audit.

The company then repeats the access review on October 1, November 1, and December 1. If a technician changes roles, the owner updates the map and permissions immediately rather than waiting for the next monthly review. If the portal provider cannot produce access logs, the company records that gap, asks for an alternative report, and decides whether the contract or system needs to change.

Quick checklist

• List every type of sensitive information in the system. - Record each legal, contractual, or internal requirement. - Create user roles based on job duties. - Enable multi-factor authentication and automatic updates. - Set session locking and logging where the system supports them. - Assign an owner and backup owner for each control. - Save access reviews, tickets, reports, and test results. - Test account removal and backup recovery before launch. - Review the map after system, staff, or contract changes.

The expected result is not a perfect spreadsheet. It is a working connection between the portal, the requirements, the daily tasks, and the evidence. That connection makes decisions faster because staff members know what they may do, what they must check, and what they must record.

Mistakes That Break the Compliance Map

Treating compliance as a policy folder

A business may write an access policy and store it in a shared folder, but never review actual users or record removals. The policy describes an intention; the system records what happened. An auditor will usually need both.

Do this: Compare the written rule with a current user export, a recent access review, and one completed offboarding ticket.

Not this: Point to a policy and claim that it proves every employee followed it.

Giving everyone administrator access

Small teams often grant broad access because it feels quicker. That choice increases the damage from a stolen account, an accidental deletion, or an unauthorized change. It also makes reviews difficult because the business cannot explain why each person needs powerful permissions.

Do this: Start with the smallest role that supports the job. Record a business reason for any exception and set a review date, such as 30 days later.

Not this: Give administrator rights permanently because a worker might need them someday.

Relying on a vendor’s security claim

A cloud provider may advertise strong security, yet your plan may require a report, setting, or response time that the provider does not support. Responsibility does not disappear when you move information to the cloud.

Do this: Ask the provider how you will configure access, retrieve logs, receive incident notices, delete or export data, and obtain evidence. Record unanswered questions as risks with owners and deadlines.

Not this: Mark a requirement complete because the vendor uses the word “secure” on its website.

Compliance becomes useful when it guides a real choice: which account to disable, which setting to enable, which contract term to confirm, and which record to save. Build the Compliance Map around those choices, keep it current, and use it whenever technology or responsibilities change. That habit turns compliance from an occasional audit scramble into a clear part of everyday IT work.

End of chapter one. 39 more chapters in the full book.