Domain Renewal Automation: Building a Portfolio Control System

A missed domain renewal can interrupt a business, weaken a brand, or put a valuable asset at risk. The answer is not simply to switch on auto-renew. Reliable renewal operations combine a trustworthy inventory, clear ownership, payment continuity, well-timed alerts, and a tested process for exceptions.

This guide explains how founders, operators, domain buyers, and brand teams can build a practical renewal control system. It is operational guidance, not legal, financial, or security advice. Renewal dates, expiration processes, available recovery options, and account features vary by registrar, registry, and domain extension. Confirm the current terms that apply to each name rather than relying on a single universal calendar.

A renewal system is the set of records, controls, people, and procedures that helps an organization keep control of its domains and make timely decisions about renewing them. Automation can reduce manual work, but it cannot make a bad inventory accurate, resolve unclear ownership, or guarantee that a payment will succeed.

A sound system should answer six questions for every domain:

1. What is the domain, and where is it registered?
2. When is its next renewal or expiration milestone?
3. Who is accountable for its business use and renewal decision?
4. How will the renewal be paid, and how will a payment failure be detected?
5. What should happen if the normal renewal path fails or the domain is no longer wanted?
6. Can the organization later verify what happened and why?

These questions matter whether a portfolio contains a handful of company domains or a large collection of brand, product, defensive, and investment names. A spreadsheet may be sufficient for a small, stable portfolio if someone actively maintains it. A more complex portfolio may need a shared system, registrar reporting, scheduled notifications, and documented escalation paths. The important distinction is not the tool; it is whether the process reliably brings the right information to the right person in time.

The date shown in a registrar account is important, but it should not be treated as a complete description of what happens next. Renewal, expiration, grace periods, deletion, and possible recovery are governed by the applicable registration arrangements and policies. ICANN’s renewal FAQ and Expired Registration Recovery Policy describe requirements and processes for covered generic top-level domains, but individual circumstances and other extensions may differ.[1][2]

A domain that has expired is not necessarily immediately available for someone else to register. That is not a safe operating assumption, however. A registrant may lose the ability to use the domain, recovery may involve additional steps or cost, and the timing and available options depend on the applicable registrar and registry arrangements. ICANN’s policy materials describe certain notices and expiration-related processes for covered registrations; they do not make every domain’s recovery path identical.[1][2]

For operational planning, track several distinct dates and events rather than using one field called “renewal date”:

• Current registration expiration date: the date displayed in a reliable registrar or registry record, subject to the provider’s conventions.
• Internal decision deadline: the latest date by which a responsible person must confirm whether the organization intends to renew.
• Payment readiness deadline: the date by which the payment method and renewal settings must be checked.
• Escalation dates: points at which unresolved issues are sent to a manager, finance contact, or domain administrator.
• Confirmed outcome: evidence that the renewal completed, the domain was deliberately allowed to expire, or an exception remains open.

These internal dates are management controls, not promises about how much time a registrar or registry will allow after expiration. Do not use an assumed grace period as the organization’s operating buffer. Verify the applicable process directly with the registrar and, where necessary, the relevant registry.

An inventory field is only useful if people know where its value came from and when it was checked. Record the registrar account or data source, the date the value was last verified, and—where practical—the person or system that verified it.

If two sources disagree, treat the discrepancy as an exception. Do not silently choose the later date. Check the registrar’s current account information, renewal notices, and relevant registration terms. For especially important domains, resolve discrepancies well ahead of the internal decision deadline.

Automation is only as reliable as the data it uses. Start by creating one authoritative inventory, or a defined system of record with a clear owner. Avoid letting one team’s spreadsheet, another team’s registrar login, and a finance export become competing versions of the portfolio.

A useful inventory usually includes:

| Field | Why it matters | |---|---| | Domain name | Identifies the registration and helps detect omissions or duplicates. | | Registrar and account identifier | Shows where the registration is managed without exposing credentials in the inventory. | | Expiration or renewal date | Supports scheduling and escalation. | | Date last verified and verification source | Makes the date’s reliability visible. | | Business owner | Identifies who can explain the domain’s purpose and business need. | | Renewal approver | Identifies who makes or confirms the renewal decision. | | Operational administrator | Identifies who can carry out account changes or investigate failures. | | Renewal status | Distinguishes auto-renew enabled, manual renewal, pending decision, renewed, or exception. | | Payment owner or funding route | Shows how the renewal is expected to be paid. Avoid storing full payment credentials in an unsecured inventory. | | Criticality and use | Explains whether the name supports a website, email, customer journey, product, redirect, defensive registration, or investment holding. | | Renewal term or planned term | Helps distinguish the intended purchase period from the default setting. Confirm the registrar’s available options. | | Decision status | Records renew, allow to expire, transfer, consolidate, or investigate. | | Evidence link | Points to a receipt, registrar confirmation, approved decision, or incident record. | | Notes and exceptions | Captures special handling, dependencies, disputes, or unusual provider arrangements. |

Do not make “criticality” a vague label with no practical consequences. Define what each level means. For example, a critical domain might be one used for company email or a primary customer-facing website. A lower-priority name might be a defensive registration that has no active technical dependency. The organization should decide which services and risks qualify; there is no single classification that fits every portfolio.

A system cannot renew a domain it does not know exists. Portfolio discovery should include more than a search of the main registrar account. Ask teams about domains purchased for campaigns, acquisitions, regional launches, product experiments, and individual projects. Review finance records for recurring registrar charges, account records for known registrars, and technical configurations for domains currently used by websites, email, or software services.

These checks help identify possible gaps, but none should be treated as a complete substitute for an ownership and registration review. A domain may be registered through a former employee’s account, a separate business unit, a reseller, or an acquired company. Record uncertain cases as open reconciliation items, assign an owner, and set a date for resolution.

The person who manages DNS is not necessarily the person authorized to approve a renewal. Likewise, a brand owner may be accountable for the business case but have no registrar access. Record those roles separately.

Also distinguish a domain’s registration status from its technical configuration. A domain may be renewed while its DNS points to the wrong service, or its website may appear to work even when the organization’s records are incomplete. Renewal monitoring is not a substitute for DNS, website, email, or account-security monitoring.

A calendar should do more than display expiration dates. It should create a predictable sequence of reviews, provide adequate internal time to act, and show who owns each unresolved task.

The right lead time depends on the organization’s approval procedures, payment systems, registrar arrangements, and risk tolerance. There is no universally correct number of days to start. A small team with centralized accounts may need a simpler process than a company with procurement approvals, multiple currencies, or many independent business units. Choose an internal schedule that leaves room for investigation and escalation, and verify it against the specific registration terms.

One possible operating pattern is:

1. Early review: Confirm the domain’s purpose, owner, current registrar, and intended renewal decision.
2. Readiness check: Verify the account’s renewal setting, payment route, contact information, and any approval requirement.
3. Decision deadline: Obtain a documented renew, transfer, investigate, or allow-to-expire decision.
4. Final pre-expiration escalation: Escalate any unresolved critical domain to the accountable manager and registrar administrator.
5. Outcome confirmation: Check for a completed renewal or approved non-renewal; retain evidence.
6. Post-event reconciliation: Review exceptions, update the inventory, and confirm that the next cycle is scheduled.

An organization can translate these stages into specific calendar offsets after evaluating its process. For example, it might begin an internal review several months ahead, set a decision deadline well before expiration, and reserve a separate escalation date. The exact interval should be documented as an organizational control, not presented as a registrar grace period.

• Use more than one notification channel for critical domains. A shared task queue plus email, for example, can be more resilient than a single person’s inbox.
• Send alerts to role-based destinations where possible. A renewal notice should not vanish when an employee changes jobs.
• Make each alert actionable. Include the domain, registrar, due date, accountable owner, status, and next required action.
• Avoid alert fatigue. Group routine items when appropriate, but keep urgent exceptions visible.
• Track acknowledgment, not just delivery. A notification sent is not the same as a decision made.
• Escalate based on unresolved work. If the owner has not responded, route the task to a named backup or manager.
• Keep an exception queue. Data conflicts, account-access problems, declined payments, and uncertain ownership need active tracking.

A product domain is due for renewal. The calendar sends a task to the product owner, who has left the company. The notification is delivered, but nobody acts. A stronger system would detect that the assigned owner is inactive, route the task to a backup, and keep it open until a current person accepts responsibility. If the domain supports sign-in or customer email, the system should also flag it for higher-priority review.

This illustrates why a calendar needs ownership rules and escalation logic. A date without an accountable person is only a reminder to hope someone notices.

Auto-renew can reduce the chance that a routine renewal is missed, but it does not resolve every failure mode. The setting may be disabled, a payment method may be expired or declined, an account may be inaccessible, or a domain may be subject to a separate approval or billing process. A successful charge also does not prove that the correct person approved the expense or that the domain remains worth keeping.

For each domain, record the intended renewal mode and review it:

• Auto-renew enabled: Confirm that the setting is visible in the correct account and that the payment path is current.
• Manual renewal: Assign an approver and a separate operator, or clearly state when the same person performs both roles.
• Renewal decision pending: Set an owner and a decision deadline; do not leave the status open-ended.
• Renewal intentionally disabled: Record the approver, rationale, and date of the decision.
• Unknown status: Treat as a risk requiring investigation, not as “probably on.”

Auto-renew should be reviewed when a domain changes business use, account ownership changes, payment details change, an acquisition is completed, or the organization is planning a registrar transfer. Do not assume a setting will behave identically across registrars or registration types. Confirm the current account configuration and provider terms.

For critical names, separate the intent to renew from the mechanism that performs the renewal.

• The business owner or authorized approver confirms that the organization still intends to retain the domain.
• The registrar administrator or automated process carries out the renewal.
• The system independently checks that the renewal completed and records evidence.

This separation helps prevent a domain from being retained indefinitely without review, while also reducing reliance on one person to remember a manual transaction. It can be adapted for a small team: the same person may hold more than one role, but the system should still record the decision and the outcome separately.

Domain renewal is a cross-functional responsibility. A workable process identifies who decides, who operates, who pays, and who receives alerts. These roles may be distributed among brand, IT, finance, procurement, legal, and business teams.

A simple responsibility model might include:

• Business owner: Explains the domain’s purpose and recommends whether to keep it.
• Renewal approver: Authorizes the renewal or non-renewal under the organization’s spending rules.
• Registrar administrator: Manages the registrar account, settings, contact details, and operational actions.
• Finance or payment owner: Maintains the approved billing route and helps resolve payment issues.
• Portfolio custodian: Maintains the inventory, verifies data, and tracks upcoming work.
• Escalation owner: Resolves overdue decisions or ownership conflicts.
• Security or identity administrator: Supports account-access controls, recovery arrangements, and staff changes.

One person can cover several roles in a small organization, but a role should not disappear merely because the team is small. Write down who is acting in each capacity and who takes over when that person is unavailable.

Registrar accounts can control valuable assets and related settings. Grant access according to business need, avoid shared credentials where the provider supports individual access, and remove access when responsibilities change. NIST’s access-control guidance emphasizes controlling access through defined permissions and authorized users; its small-business guidance can help teams think systematically about who should be allowed to perform which actions.[3]

A practical role design may distinguish:

• People who can view the portfolio and renewal dates.
• People who can approve renewals.
• People who can change account contacts or payment settings.
• People who can alter DNS or transfer registrations.
• People who can manage account security and recovery.

These permissions should reflect the registrar’s actual capabilities. Do not assume that every provider offers fine-grained roles or that its access model maps perfectly to the organization’s preferred separation of duties.

Account security is broader than renewal automation. Use the security controls supported by the provider, keep recovery information current, and document how authorized administrators can regain access if a primary operator is unavailable. Treat credentials and payment information as sensitive; do not place passwords or full payment details in a general-purpose inventory.

Employee departures and role changes are predictable operational events. Add domain account checks to joiner, mover, and leaver procedures:

• Identify registrar accounts and domains the person administered.
• Transfer operational responsibility to a named current owner.
• Remove or adjust access according to the organization’s access process.
• Verify that recovery contacts and billing contacts remain current.
• Confirm that alerts do not still route exclusively to the departing person.
• Update the inventory and record the change.

For a domain registered in an individual’s personal account, do not assume that a spreadsheet entry alone resolves the ownership or control issue. Escalate it for an appropriate organizational review and use the registrar’s documented processes. Questions about legal ownership, contracts, or disputes require qualified professional advice.

A renewal can fail because the payment route is no longer usable, even when the domain and calendar records are correct. Payment continuity should therefore be checked before a renewal is due, not only after a charge fails.

Potential issues include an expired card, a changed billing account, an unrecognized transaction review, a procurement approval delay, a billing contact who has left, or an account that uses a different payment method from the rest of the portfolio. The appropriate controls depend on the organization and the registrar.

Before a renewal cycle:

• Confirm the approved payment method is still valid and authorized for the account.
• Confirm that the billing contact and notification address are current.
• Understand whether the renewal is expected to charge automatically or require manual action.
• Check whether internal procurement or purchase-order steps apply.
• Make sure the person who can resolve a declined transaction is identifiable and reachable.
• Review how charges and receipts are reconciled to domains.
• Avoid storing sensitive payment credentials in an unprotected portfolio file.
• Record how the organization will respond if a charge is rejected or cannot be approved in time.

For portfolios distributed across several registrar accounts, maintain a payment-owner map. It should show which team or approved billing route supports each account without unnecessarily exposing financial details. When a domain is transferred or consolidated, verify that the new account’s billing arrangement is in place before relying on its renewal setting.

A renewal reminder disappearing from a task system is not evidence that a domain renewed. Nor is a charge notification always sufficient to identify which domain or registration period was covered. Reconcile the registrar’s confirmation, updated registration information, and financial record as appropriate to the organization’s controls.

If a renewal cannot be confirmed, keep the item open. Contact the registrar through a verified channel, check the account directly, and record the result. Do not treat an automated email as conclusive if it conflicts with the registrar account or another reliable source.

A control system is tested most when something goes wrong. Common exceptions include missing data, disputed responsibility, inaccessible accounts, failed payment, an unapproved expense, conflicting renewal decisions, and uncertainty about the domain’s business use.

Define an exception process that answers:

1. Who receives the exception?
2. How quickly must the recipient acknowledge it?
3. Who can make an interim decision for a critical domain?
4. What is the escalation path if the owner is unavailable?
5. What evidence must be captured?
6. Who closes the exception and updates the inventory?

Set internal response expectations according to the risk and the time remaining, rather than assigning the same priority to every domain. A name that supports company email may warrant immediate escalation when its renewal status is unclear. A parked name with no known technical or brand dependency may follow a less urgent path, subject to the organization’s investment and legal review.

| Exception | Initial response | Closure evidence | |---|---|---| | Expiration date differs across records | Check the registrar account and relevant provider information; correct the inventory only after verification. | Source, verification date, and corrected record. | | Owner is unknown or has left | Assign a temporary accountable owner; investigate use, account control, and business purpose. | Named owner and documented decision. | | Auto-renew status is unclear | Inspect the relevant account and confirm the intended setting. | Status, verifier, and date checked. | | Payment is declined or cannot be approved | Contact the authorized finance or payment owner and registrar; escalate according to criticality. | Payment resolution or approved alternative decision. | | Registrar account is inaccessible | Use the provider’s documented recovery route and involve the appropriate account or security administrators. | Restored authorized access and updated recovery ownership. | | Business teams disagree about renewal | Pause routine closure, identify the decision authority, and document the decision and rationale. | Approved outcome and responsible approver. | | Domain appears registered outside the organization’s expected account | Investigate account, contract, and operational dependencies; seek qualified advice if rights or ownership are disputed. | Resolved control record or open issue with an assigned owner. | | Renewal completed but inventory did not update | Reconcile the registrar record and financial evidence; update the next cycle. | Updated record and confirmation reference. |

For critical domains, specify who can act if the normal approver or registrar administrator is unavailable. An emergency path should not mean unrestricted access for everyone. It should identify authorized backups, the circumstances under which they may act, how they verify the domain and payment, and how they document the decision afterward.

Test this path in a controlled way. For example, ask a backup administrator to locate the correct account, identify the renewal status, find the escalation contact, and explain how access recovery would be initiated—without making an unnecessary change. Record gaps and assign them for correction. Testing should follow the organization’s security and provider requirements.

An audit trail helps a team answer what happened, who approved it, and whether the organization followed its own process. It is also useful when a portfolio changes hands, when a finance team reconciles recurring expenses, or when a renewal failure needs investigation.

For each renewal decision or significant exception, retain a concise record of:

• The domain and registrar account involved.
• The date the status was checked.
• The source used to verify the expiration or renewal status.
• The business recommendation and authorized decision.
• The person or process that performed the renewal or other action.
• The resulting registrar confirmation or other appropriate evidence.
• Any payment issue, escalation, or exception.
• The next renewal date and assigned owner.

Keep the audit trail proportionate. A small portfolio may use a controlled change log and saved confirmations. A larger portfolio may use a ticketing or asset-management system. Whatever the format, records should be understandable to someone who was not involved in the original transaction.

Allowing a domain to expire should be a deliberate decision, not the absence of action. Record who approved the decision, why the name is no longer required, whether the domain supports any active service, and whether any planned transition or technical cleanup remains. The organization should consider operational and brand dependencies before deciding to stop renewing. Where legal rights, customer obligations, or disputed ownership are involved, get qualified advice rather than treating a routine renewal workflow as a substitute for legal review.

A decision can also change. If a business later wants to recover a domain that was not renewed, available options and timing depend on the applicable registrar and registry processes. Do not promise that a previously held domain can be recovered or that it will remain available.[1][2]

The simplest workable system is often better than an elaborate one nobody maintains. Choose tools based on the number of accounts, number of responsible teams, approval complexity, and consequence of failure.

For a small portfolio, a shared inventory and calendar may be enough if:

• Every domain has a named owner and backup.
• Dates are verified against the registrar.
• Alerts reach a shared location, not just one employee.
• Renewal decisions and outcomes are recorded.
• Access and payment responsibilities are clear.
• Someone reviews the inventory on a schedule.

Use access controls and change history appropriate to the organization. A spreadsheet that anyone can edit without a record of changes may be difficult to trust, especially when multiple teams share responsibility.

A larger or more complex portfolio may benefit from:

• Centralized domain inventory and ownership records.
• Registrar account mapping and account-level payment ownership.
• Automated reminders based on verified date fields.
• Escalation when a task is overdue or unacknowledged.
• Status synchronization or periodic checks against registrar data.
• A queue for exceptions and data conflicts.
• Approval records and renewal evidence.
• Reporting by business unit, criticality, registrar, and upcoming deadline.

Before introducing automation, test what data the system can actually obtain. Do not assume a registrar integration reports every domain, uses the same date conventions as the inventory, or captures every relevant renewal state. Verify records and document known limitations.

A useful automated workflow can:

1. Identify records that are due for review.
2. Notify the business owner and renewal approver.
3. Record acknowledgment and the chosen action.
4. Escalate overdue decisions.
5. Notify the registrar administrator or payment owner when necessary.
6. Request confirmation after the expected action.
7. Update the next review cycle only after the result is verified.
8. Preserve the decision and evidence in an audit record.

Automation should stop or flag the workflow when key data is missing. If a record lacks a registrar, owner, or reliable expiration date, sending a routine reminder may create false confidence. Route it to data remediation instead.

A recurring operating rhythm makes renewal management less dependent on emergency attention. Adapt the schedule to portfolio size and risk.

• Identify all known domains and registration accounts.
• Verify current registration details through reliable sources.
• Record business use, owner, approver, administrator, and payment route.
• Check current renewal settings and contact details.
• Identify any domains registered through individual or third-party accounts.
• Add dependencies and open questions to the exception queue.
• Set internal review dates and escalation owners.

• Review the upcoming renewal queue.
• Confirm unresolved critical domains have active owners.
• Check open payment, access, and date-conflict exceptions.
• Reconcile renewals completed during the period.
• Update records after personnel or account changes.

The frequency should reflect the volume and risk of the portfolio. A team may choose a different review cadence, but it should ensure that an issue can be detected with enough time for its approved response.

• Reconcile the inventory against registrar accounts and other evidence.
• Review account access and remove obsolete permissions.
• Confirm backup contacts and recovery routes.
• Review which domains remain in use and who approves retention.
• Test escalation and account-continuity procedures.
• Evaluate whether the current tooling still fits the portfolio.

A domain inventory should not be treated as a one-time cleanup project. Businesses add domains, discontinue products, acquire companies, change registrars, and reorganize teams. Each event can invalidate an old owner, payment route, or technical-use record.

Metrics should help operators find control gaps, not reward activity for its own sake. Useful measures may include:

• Percentage of domains with a verified expiration date.
• Percentage with a current business owner and renewal approver.
• Number of unresolved records with unknown registrar or account.
• Number of critical domains with unconfirmed renewal status.
• Number of overdue renewal decisions.
• Number and age of payment or access exceptions.
• Percentage of completed renewals with retained confirmation.
• Number of domains intentionally allowed to expire without a recorded decision.
• Number of alerts routed to inactive or incorrect contacts.

Define the calculation and the review owner. A “100% confirmed” figure is meaningless if the inventory omits domains or if the underlying source has not been checked. Use periodic reconciliation to test coverage, and report exceptions plainly rather than hiding them in an aggregate score.

Suppose a company manages three types of domains:

• A primary company domain used for its website and email.
• Several product domains used for customer-facing services.
• A set of defensive and campaign registrations with varying current value.

The primary domain receives a high criticality classification because multiple services depend on it. The organization assigns a business owner, an authorized approver, a registrar administrator, a backup administrator, and a payment owner. Auto-renew is enabled if supported and intended, but the calendar still requires a pre-renewal readiness check and post-renewal confirmation.

Product domains receive named product owners. If a product is retired, its owner must recommend whether to retain the domain and confirm whether any services or communications still rely on it. The renewal decision is recorded even if the answer is “do not renew.”

Defensive and campaign registrations are reviewed in a grouped portfolio cycle, but each still has an accountable owner and an explicit decision. Items with unclear purpose go to an exception queue rather than being automatically renewed forever or silently dropped.

In this model, automation routes tasks and tracks decisions. People still determine business need, resolve unclear rights, verify account settings, and make approved decisions. The system provides continuity and evidence; it does not replace judgment.

Use this checklist to establish or improve a portfolio renewal control system.

• [ ] Create an authoritative domain inventory.
• [ ] Record the registrar and account identifier for each registration.
• [ ] Verify expiration dates and record when and how each was checked.
• [ ] Identify business use, criticality, and current dependencies.
• [ ] Reconcile the inventory against known accounts, technical uses, and payment records.
• [ ] Track uncertain records as assigned exceptions.

• [ ] Name a business owner, renewal approver, and operational administrator.
• [ ] Name backups for critical responsibilities.
• [ ] Separate approval, payment, and account-operation roles where practical.
• [ ] Review registrar access and remove outdated permissions.
• [ ] Keep account recovery and contact information current.
• [ ] Include domain account handoffs in staff-change procedures.

• [ ] Set internal review and decision deadlines ahead of expiration.
• [ ] Define an escalation path for unacknowledged alerts.
• [ ] Route alerts to durable, monitored destinations.
• [ ] Make alerts specific and actionable.
• [ ] Flag missing or conflicting data instead of treating it as normal.
• [ ] Confirm renewal outcomes before closing tasks or resetting the next cycle.

• [ ] Record the intended renewal mode for each domain.
• [ ] Verify the setting in the relevant registrar account.
• [ ] Check payment continuity and identify who can resolve a failure.
• [ ] Confirm procurement or approval requirements.
• [ ] Avoid storing sensitive payment details in general inventory records.
• [ ] Review settings after transfers, account changes, or business-use changes.

• [ ] Define how date conflicts, access failures, declined payments, and ownership gaps are handled.
• [ ] Set critical-domain escalation expectations.
• [ ] Record renew, transfer, investigate, and allow-to-expire decisions.
• [ ] Retain suitable confirmation and approval evidence.
• [ ] Test the backup and emergency process.
• [ ] Review unresolved exceptions on a recurring basis.

A dependable renewal operation is not a collection of reminders. It is a control system that combines accurate records, clear decision rights, workable account access, payment readiness, exception handling, and evidence that the intended action actually occurred.

Auto-renew can be a valuable layer, especially for domains the organization has decided to retain. It should sit alongside—not replace—business review, calendar escalation, payment checks, and outcome verification. Likewise, a calendar is useful only when its dates are trustworthy, its alerts reach accountable people, and unresolved work moves to someone who can act.

Start with the portfolio you can verify. Assign owners, identify critical dependencies, and resolve unknown accounts before adding more automation. Then automate the repeatable steps while preserving human review for ambiguous or consequential decisions. Revisit the system as the portfolio, team, and provider arrangements change. The result is not a guarantee that renewal problems will never occur; it is a more visible, accountable, and recoverable process for managing them.

[1]: https://www.icann.org/resources/pages/domain-name-renewal-expiration-faqs-2018-12-07-en "ICANN, Domain Name Renewal and Expiration FAQs"

[2]: https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-28-02-2013-en "ICANN, Expired Registration Recovery Policy"

[3]: https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/access-control "NIST, Small Business Cybersecurity: Access Control Guidance"