What we govern: six control surfaces that decide your audit

Mid-market audits are not lost on the controls that compliance teams know about and have documented. They are lost on the controls that were assumed, misconfigured, or quietly drifted in the months between when someone last checked and when the auditor asked. The difference between a clean audit and a remediation list is rarely a surprise about strategy. It is almost always a surprise about specifics.

Governing systems well means knowing which surfaces actually determine audit outcomes. Not every setting in every system is a material control. But there are six areas where the gap between what a policy says and what a system is actually doing tends to be consequential — where a single misconfiguration, an undocumented change, or an oversight in vendor oversight directly affects what an auditor finds and what a regulator can rely on. These six surfaces are where Bylaw Evidence focuses its continuous governance work, and they are where most mid-market compliance programmes are thinnest.

What follows is an honest account of each surface: what it governs, why it matters, and what drift on that surface looks like in practice. The purpose is not to describe every possible control in every possible framework. It is to give a compliance lead or a security-minded executive a clear picture of where the material risk is, and what being on top of it actually requires.

01 / Access: who can reach what

Access is the foundational control surface. Everything else in a governance programme assumes that the right people can reach the right systems and the wrong people cannot. When that assumption is wrong, the controls built on top of it are also wrong — regardless of how carefully they were designed.

The identity provider is the control plane for access in most mid-market environments. Okta, Microsoft Entra ID, and Google Workspace are the most common. What the identity provider enforces — which users are active, which groups they belong to, which applications they can reach, what authentication requirements apply to each — determines the effective access state of the company's systems. A Salesforce permission set that looks correct in Salesforce means nothing if the Okta group feeding that permission set contains users who should not be there.

Access drift is constant. Employees change roles and their old permissions are not removed. Contractors finish engagements and their accounts remain active. A system administrator grants temporary elevated access during an incident and the elevation persists. These changes happen at the speed of daily operations, not the speed of quarterly access reviews. A control that is checked four times a year is not checking access. It is sampling access, on the days that matter least — after the team has cleaned up in preparation for the review.

Continuous access governance means checking, on a defined schedule that reflects the risk profile of each system, that the active user population matches the expected population, that privilege levels match what the policy and the job function require, and that MFA enforcement is covering every user in scope, not just the ones the team thought to include. SOC 2, ISO 27001, HIPAA, and GDPR all require effective access controls. What they share is the word "effective" — not documented, not designed, but actually working.

02 / Configuration: baselines and their drift

Configuration governance is the discipline of verifying that the security settings in each system match what the policy requires — and continuing to verify that as the systems change. Retention policies, data loss prevention rules, external sharing settings, encryption standards, audit log settings, and security baselines are all configurations. All of them can be changed by an administrator with the right access. All of them drift.

In Microsoft 365, the relevant configuration surface is wide. Conditional access policies, retention labels and policies, DLP rules, Teams external access settings, SharePoint sharing configurations, and Defender settings all have material security implications. A DLP rule that was active last quarter may have been modified to allow an exception that was never removed. A retention policy that applies to most mailboxes may not apply to a newly created shared mailbox. A conditional access policy that correctly enforces MFA may have an exclusion added for a service account that has since been granted broader permissions than the account was originally designed to hold.

In Salesforce, configuration drift affects profiles, permission sets, field-level security, sharing rules, and connected app settings. In Google Workspace, it affects sharing settings, Drive access controls, and admin role assignments. In AWS, it affects encryption settings, S3 bucket access policies, security group rules, and CloudTrail logging configuration. Each of these is a surface where a single change by a well-intentioned administrator, made without going through a change control process, can create a gap between the policy and the system's actual state.

Configuration governance requires a defined baseline — a documented expectation of what each material setting should be — and a continuous check that the live system matches that baseline. When it does not, the deviation is recorded at the moment it is detected, not at the moment someone decides to look.

03 / Change: approval trails in production

Change management is one of the controls most frequently cited in audit findings. The reason is not that companies lack change management processes. Most mid-market companies have them. The reason is that the process and the evidence of the process being followed are often two different things.

An auditor looking at change management wants to see that production changes were approved before they were made, that the approval was by a person with the authority to approve that type of change, that the change was tested in a non-production environment first, and that there is a record of each step. The policy usually describes exactly this sequence. The evidence record often cannot demonstrate it, because the approvals happened in a Slack message, or the ticket was closed after the change rather than before, or the test environment was skipped under time pressure and no one documented the exception.

Governing the change surface means checking that the change management process is producing records that match its own requirements. Which systems are in scope for change management? Where are change requests created and approved? Are approvals being obtained before changes are made, or are they being back-filled? Are changes to Salesforce production configuration going through the same process as changes to AWS infrastructure, or is one surface exempt in practice even if not in policy?

For companies operating under SOC 2 Type II, the change management control is checked across the full audit period, not just a sample point. Twelve months of changes need to be traceable. A programme that produces that traceability continuously — where every change to an in-scope system is recorded and compared against the expected approval evidence — is not doing extra work. It is doing the work the framework actually requires, at the cadence the framework actually requires it.

04 / Vendors: third-party oversight that actually runs

Third-party risk management appears in virtually every compliance framework as a required control. In practice, it is one of the most commonly underdeveloped areas in mid-market compliance programmes. The policy exists. The vendor register exists. The requirement to conduct annual reviews exists. The reviews themselves are often incomplete, overdue, or conducted in a form that would not survive scrutiny.

Vendor oversight requires more than a list. It requires a documented scope — which vendors are in scope for review, based on what criteria? A vendor that processes personal data is a different risk from a vendor that provides a project management tool. The classification determines the review frequency and depth. It requires a review process — what is actually examined during a review? The vendor's SOC 2 report, if they have one? Their responses to a security questionnaire? Their contractual data processing terms? It requires evidence that the review happened — not that someone marked it complete in a tracker, but that there is a record of what was reviewed, by whom, on what date, and what the findings were.

AI vendors add a new dimension to third-party oversight. When a company adds Salesforce Einstein, Microsoft Copilot, or a third-party AI tool that processes business data, the vendor oversight question is not just "do they have a SOC 2?" It is "what data does this feature access, what does the vendor do with it, and what configuration is required to limit that access to what the policy permits?" Governing this surface means adding AI-capable vendors to the scope of third-party review with the right questions, not just the standard ones.

05 / Data handling: where sensitive data lives and how movement is governed

Data handling governance answers a set of questions that are deceptively simple to state and genuinely difficult to keep current: where does sensitive data live, who can move it, and what controls govern that movement? Under GDPR, HIPAA, and many state privacy laws, the answers to these questions are not optional documentation. They are legal requirements. An organization that cannot answer them accurately is in a different category of risk from one that can.

Data mapping — the process of identifying where personal data, health information, financial records, and other sensitive data categories are stored and processed — tends to get done once and then age badly. Systems get added. New integrations move data to new places. A marketing team connects a new tool that exports Salesforce contact records. A finance team starts storing payroll data in a cloud service that was not in the original data map. The map becomes a record of where the data used to be, not where it is now.

Governing the data handling surface means maintaining a current view of where sensitive data lives across the relevant systems, verifying that the controls governing data movement — DLP rules, sharing restrictions, export permissions — are active and configured correctly, and checking that retention and deletion schedules are running as the policy requires. It also means checking that sensitive data is not appearing in places it should not be: in public-facing storage, in systems that lack the required security controls, or in the hands of users whose access was not designed to include it.

Regulators asking about data handling under GDPR or HIPAA are asking about current state, not historical documentation. The governance programme that answers these questions well is the one that has been tracking current state continuously, not the one that assembled a data map for the last audit and has not touched it since.

06 / AI oversight: features, scope, and human review

AI oversight is the newest addition to the set of material control surfaces, and it is already required under frameworks that are in force. The EU AI Act creates direct obligations for companies deploying certain categories of AI system. SOC 2 auditors are adding AI-related inquiries. ISO 42001 provides a management system standard for AI governance that is increasingly referenced in enterprise procurement. The window in which AI oversight was optional is closing.

Governing the AI surface starts with a current feature inventory. Which AI capabilities are active in the systems the company runs? Salesforce Einstein and Agentforce features, Microsoft Copilot and Copilot Studio, Google Duet AI and Gemini in Workspace, AWS AI services, and any third-party AI tools that have been connected to company data — all of these need to be inventoried, with their data-access scope documented. A feature inventory that is done once and not maintained is not an inventory. It is a record of the AI features that were active the day someone looked.

Beyond inventory, AI oversight requires documented human review processes for the AI features that make decisions or recommendations with material consequences. Which outputs are reviewed before they are acted on? Who reviews them, using what criteria, and how is that review recorded? For high-risk AI applications under the EU AI Act, these questions are not framework guidance. They are legal requirements with documented obligations attached.

The organisations that will be in the strongest position when AI governance obligations sharpen are the ones that already have a current feature inventory and a documented human review process — not the ones that are preparing to create them.

Deployment scope is the third component. AI features that are deployed broadly — across all users, across all data types, without configuration limits — create a different risk profile than features that are deployed with documented access restrictions and population limits. Governing deployment scope means verifying that the configuration matches the documented intent, and checking that configuration continuously, not just when someone asks.

The six surfaces described here — access, configuration, change, vendors, data handling, and AI oversight — are not the entirety of what governance programmes address. They are the surfaces where the gap between policy and practice is most consequential, and where continuous independent verification makes the clearest difference to what an auditor finds, what a regulator relies on, and what an enterprise buyer trusts.