Answer First
Definition: An entry management compliance audit trail is the structured, timestamped record set — spanning ownership assignments, role-based access controls, status transitions, and immutable change logs — that demonstrates to SOC2 and ISO 27001 auditors that every public-facing subdomain and redirect entry within an organization’s domain portfolio is accounted for, controlled, and traceable to an authorized actor.
Why: When auditors evaluate your change management and access control practices, they do not ask “do you have an entry management platform?” They ask for evidence that your organization knows what endpoints exist, who controls them, who can change them, and what happened to them over the audit period. A manual DNS spreadsheet cannot answer those questions because it captures a snapshot, not a story. An entry management layer with ownership, status, and change logging turns those auditor questions from a multi-day scramble into a structured export — because the evidence was being collected the entire time.
Example: An auditor reviewing SOC2 CC6.1 (change management) asks your team to demonstrate that campaign subdomain entries retired after Q3 were properly decommissioned with approval. In a spreadsheet-based process, you would need to cross-reference the DNS provider’s raw change log against a shared spreadsheet, find the Slack thread where someone approved the decommission, and hope all three sources agree. With an entry management layer, you open the entry’s change log, see the status transition from “active” to “retired,” the timestamp, the user who executed it, and the ownership record — all in one place. You export the log, attach it to the auditor’s evidence request, and close the item.
Key Facts
- SOC2 Trust Services Criteria CC6.1 and CC7.2 require evidence of change management and logical access controls. ISO 27001 Annex A controls A.8.1, A.9.2.1, A.12.1.2, and A.12.4 collectively require asset inventory, user access management, change management, and event logging. Subdomain entries and their redirect configurations are information assets that fall under every one of these requirements.
- RFC 9110 defines HTTP redirection semantics (status codes 301, 302, 307, 308) that govern how redirects behave at the protocol level, but it does not define who may configure them or how organizations should document them. The compliance gap sits right there: the protocol handles the redirect, and the auditor handles the question about who authorized it. The entry management layer bridges that gap. (RFC 9110, Section 15.4)
- DNS provider audit logs record that a record changed; they do not record why it changed, what business context the change served, which campaign or team owned the entry, or whether the new destination was validated before the change went live. These are precisely the dimensions auditors need to see.
- Redirect chains — where one entry forwards to another, which forwards to a third — create compounding audit risk because a break at any link means the entire chain fails. MDN’s HTTP redirection documentation catalogs the redirect types but does not address chain governance. Each link in the chain is a separate entry that needs its own ownership record, status tracking, and change history. Without an entry management layer, a five-link redirect chain means five separate DNS records to audit with no unified view.
- The practical limits of manual entry governance become visible at surprisingly low scale. We discussed how acquisition-driven subdomain sprawl creates consolidation pressure and audit exposure in our acquisition subdomain entry consolidation playbook. Even a single acquired entity can bring dozens of undocumented subdomain entries, each one a potential finding during the next audit.
Expert Explanation
What Auditors Actually Request — and Why Spreadsheets Fall Short
A SOC2 or ISO 27001 audit is not a single monolithic interrogation. It is a series of evidence requests, each one asking the organization to prove that a specific control operated effectively over the audit period. When those requests touch on subdomain entries and redirects, they typically take three forms.
First, the asset inventory request: “Provide a complete inventory of public-facing endpoints, with assigned owners, that were active during the audit period.” A spreadsheet can answer this — if it was maintained perfectly, if nobody forgot to update it, and if the auditor does not ask follow-up questions about when each entry was created or retired. The moment the auditor asks for point-in-time accuracy, the spreadsheet’s weakness is exposed: it shows the state someone remembered to record, not the state that was actually in production on any given date.
Second, the access control request: “Demonstrate that only authorized personnel can create, modify, or decommission public-facing endpoints.” DNS provider access controls answer part of this — they show who has credentials. But they rarely show what those credentials were used to do, at what time, to which specific entry, with what business justification. That is not the DNS provider’s job, and it is not what their audit logs were designed to capture.
Third, the change management request: “For each change to a public-facing endpoint during the audit period, provide the date, the actor, the nature of the change, and evidence of approval.” This is where manual processes break down completely. A typical team might have a DNS change log from the provider, a Slack channel where changes are discussed, a shared spreadsheet that someone updates after the fact, and a ticketing system where formal approvals live. None of these sources are linked. An auditor who receives four different exhibits for one change — with timestamps that do not quite align — will ask why, and the answer is rarely reassuring.
The Evidence Controls an Entry Management Layer Provides
An entry management platform that tracks ownership, status, and changes per entry addresses each of these evidence requests with a single, coherent source. The specific evidence controls break down as follows.
Ownership assignment. Every entry — whether it is a branded subdomain, a campaign short-link entry, or a redirect in a multi-step chain — carries an explicit owner field. That owner is the accountable party the auditor can trace back to. When an entry is created during a marketing sprint and the sprint lead’s name is on it, that ownership record persists through the entry’s lifecycle and becomes part of the audit trail. Ownership is not inferred from who last edited the DNS record; it is declared and tracked.
Status tracking per entry. An entry moves through defined statuses — active, paused, retired, under review — and each status transition is recorded with a timestamp and the actor who triggered it. This matters because auditors care about the full lifecycle of an asset, not just its creation. A campaign entry that ran for six weeks, was paused when the campaign ended, and was retired after a 30-day grace period tells a complete story. The auditor can see that the organization has a defined process for entry lifecycle management — not just ad hoc DNS updates.
Immutable change logs. Every modification to an entry — destination URL change, status transition, ownership reassignment, metadata update — is logged with the actor, the timestamp, and the before-and-after values. Immutability is the critical property here: the log is not editable, so the auditor can rely on it as evidence that the organization’s controls operated as described. This is the difference between a changelog someone could have edited after the fact and a changelog that the platform guarantees was recorded at the time of the event.
Role-based access visibility. The platform’s access model — who can create entries, who can modify them, who can view them — maps directly to the access control evidence the auditor requests. The auditor does not need to reverse-engineer DNS provider permission sets; they can see the access model documented in the platform’s own configuration and cross-reference it against the change logs to confirm that only authorized roles executed changes.
How This Maps to Specific SOC2 and ISO 27001 Controls
The mapping between entry management evidence and specific compliance controls is direct and auditable.
| Control Framework | Relevant Control | How Entry Management Provides Evidence |
|---|---|---|
| SOC2 CC6.1 | Logical and Physical Access Controls | Role-based access model restricts entry creation/modification to authorized users; change logs demonstrate controls operated over the audit period |
| SOC2 CC7.2 | System Component Monitoring | Entry status tracking provides point-in-time visibility into which subdomains and redirects were active, paused, or retired |
| ISO 27001 A.8.1 | Inventory of Assets | Ownership-assigned entry catalog serves as a live asset inventory of public-facing endpoints |
| ISO 27001 A.9.2.1 | User Registration and De-registration | Access model and change logs record which users had entry management permissions and when those permissions were exercised |
| ISO 27001 A.12.1.2 | Change Management | Immutable per-entry change logs with actor, timestamp, and before/after values provide direct evidence of controlled change |
| ISO 27001 A.12.4 | Event Logging | Platform-level logging captures entry lifecycle events in a structured, exportable format suitable for auditor review |
The table above is not aspirational. Each row describes evidence that an entry management platform can produce today — without custom development, without correlating multiple data sources, and without asking the auditor to accept a narrative explanation in place of structured data.
Redirect Chains and the Compounding Audit Problem
Redirect chains deserve special attention because they multiply audit surface area. We have written separately about what ops teams should check when affiliate attribution breaks somewhere in the redirect chain. From a compliance perspective, each hop in a redirect chain is a distinct entry that must satisfy the same ownership, status, and change management controls. A five-hop chain that delivers traffic correctly from a marketing perspective can still fail an audit if any one of those five entries lacks documented ownership or has an unexplained status transition.
The practical guidance is straightforward: if your redirect chains involve entries managed across multiple teams or tools, consolidate the entry management under a single platform where every hop is visible, owned, and logged. The auditor will not accept “marketing owns the first hop and engineering owns the third” as a substitute for uniform documentation.
Practical Limits
Entry management platforms provide structured evidence for the controls described above, but they are not a complete compliance solution on their own. They do not replace your broader information security management system, your risk assessment process, or your organizational policies. They do not automatically classify entries by data sensitivity, nor do they enforce approval workflows unless those workflows are built into the platform’s access model. An entry management layer answers the auditor’s questions about your subdomain and redirect entries specifically — it is a focused evidence source within a larger compliance program, not a substitute for one.
Additionally, entry management platforms cannot retroactively generate evidence for periods before adoption. If you onboard an entry management platform six months into your audit period, the platform can document entries and changes from the onboarding date forward. The first half of the audit period still requires whatever manual processes and documentation you had in place. This is why adoption timing matters: the earlier the platform is in place, the more complete the audit trail.
Decision Framework
Use this checklist to assess whether your current subdomain and redirect governance process is auditor-ready — or whether an entry management layer would close the gaps an auditor is likely to find.
- Can you produce a complete list of all active subdomain entries and redirects, with assigned owners, on demand — without updating a spreadsheet first?
- Can you show, for any given entry, who created it, when, and what its destination was at any point in the audit period?
- Can you demonstrate that only authorized roles can create, modify, or decommission entries — with evidence that unauthorized attempts were blocked or logged?
- Can you trace a single entry through its full lifecycle — created, active, paused, retired — with timestamps and actor attribution at each transition?
- Can you produce change logs that are immutable and exportable, so the auditor can verify that the logs were not edited after the fact?
- If you operate redirect chains, can you show that every hop in every chain is individually owned, status-tracked, and logged?
- Can you answer an auditor’s follow-up question about a specific entry’s change on a specific date without cross-referencing DNS logs, Slack, a spreadsheet, and a ticket system?
- If your organization acquired another company or brand in the past two years, can you prove that all inherited subdomain entries were onboarded into your governance process with documented ownership? Our acquisition consolidation playbook walks through what this looks like in practice.
Each unchecked item above represents a gap that an auditor can — and eventually will — identify. The checklist is not hypothetical; it is built from the specific evidence requests that SOC2 and ISO 27001 audits generate when public-facing endpoints are in scope.
Key Takeaways
- SOC2 and ISO 27001 audits do not ask about “entry management” by name, but they demand evidence of asset inventory, access control, change management, and event logging — all of which map directly to what an entry management platform documents for every subdomain and redirect entry.
- Raw DNS provider audit logs record that records changed; they do not capture ownership, business context, approval, or status transitions. An entry management layer provides the structured evidence that turns a DNS record change into an auditable event.
- The three evidence controls that matter most to auditors are ownership assignment (who is accountable), status tracking (what state the entry was in at any point in time), and immutable change logs (what happened, when, and who did it — with before/after values that cannot be edited after the fact).
- Redirect chains compound audit exposure because every hop is a separate entry requiring its own documentation. We covered the attribution side of this problem in our piece on affiliate redirect chain failures, and the compliance implications are the same: each undocumented hop is a potential finding.
- The practical limit is timing: an entry management platform cannot produce evidence for the period before adoption. Onboard before the audit window, not during it.
- Campaign entry lifecycle management — covered in our article on what should happen to campaign links after the campaign ends — is itself a compliance concern because retired entries that linger without documentation create inventory drift that an auditor will flag under ISO 27001 A.8.1.
FAQ
Q: Do SOC2 auditors specifically ask about subdomain and redirect management? A: They ask about change management, access control, and asset inventory — and subdomain entries with active redirects fall under all three. An auditor may not use the phrase “entry management,” but when they request evidence that your team controls who can create, modify, or decommission public-facing endpoints, your entry management platform’s role-based access records, change logs, and ownership assignments become the direct answer to that request.
Q: Can’t we just use our DNS provider’s audit log for compliance evidence? A: DNS provider logs tell you that a CNAME or A record changed — not why it changed, who approved it, which campaign or team owns it, whether the destination is still valid, or what the entry was linked to before the change. Compliance audits require context around each change, and raw DNS logs provide none of that. An entry management layer sits above DNS and captures the business context — ownership, purpose, approval, and status transitions — that turns a raw record change into auditable evidence.
Q: How does entry management map to ISO 27001 Annex A controls? A: Entry management directly supports A.8.1 (Asset Management — maintaining an inventory of subdomain entries as information assets with assigned owners), A.9.2.1 (User Access Management — role-based controls over who can register, modify, or retire entries), and A.12.4 (Logging and Monitoring — immutable change logs recording who did what and when). It also contributes to A.12.1.2 (Change Management) by documenting the full lifecycle of every entry from creation through decommissioning.
Q: What’s the practical effort to get auditor-ready with an entry management platform versus spreadsheets? A: With a spreadsheet, you need to manually correlate timestamps across DNS change logs, Slack approvals, and whoever remembered to update the sheet — and then explain any gaps to the auditor. With an entry management platform that provides ownership assignment, status tracking per entry, and immutable change logs in one place, the evidence is already structured the way auditors expect. The effort shifts from scrambling during the audit window to maintaining a single source of truth during normal operations, which is what the platform was built to do.
Sources
- RFC 9110 — HTTP Semantics, Section 15.4: Redirection 3xx — Defines HTTP redirection status codes and their semantics, establishing the protocol foundation that entry management platforms govern at the operational layer.
- MDN Web Docs — HTTP Redirections — Comprehensive reference on redirect types, behaviors, and chain mechanics, relevant to understanding what must be documented for audit purposes.
- Google Analytics Help — About campaign data and referrers — Documents how campaign parameters propagate through redirects, contextualizing why redirect integrity matters for both marketing attribution and audit traceability.
- PushULink Blog — Your Team Just Acquired Another Company: Acquisition Subdomain Entry Consolidation Playbook — Practical guidance on consolidating inherited subdomain entries into a governed entry management process.
- PushULink Blog — Affiliate Attribution Breaks Somewhere in the Redirect Chain: What Ops Teams Should Check — Examines redirect chain integrity from an attribution perspective, with direct compliance implications for multi-hop entry governance.
- PushULink Blog — What Should Happen to Campaign Links After the Campaign Ends? — Covers entry lifecycle management and decommissioning practices that support audit-ready asset inventory.