What is IT AMC in the USA and why do businesses need it?

IT AMC (Annual Maintenance Contract) in the USA is a comprehensive service agreement for maintaining all IT equipment and systems. Businesses need IT AMC for predictable costs, 24/7 support, preventive maintenance, reduced downtime, and expert technical assistance. It's the most affordable way to ensure reliable IT operations.

How much does IT AMC cost in the USA?

IT AMC pricing in the United States is scoped per engagement and depends on the number of devices, support level, and services included. Small businesses with basic coverage sit at the entry level, and comprehensive packages scale with the size of your estate. We offer the best affordable IT AMC solutions in United States with customized pricing.

What is included in managed IT services in the USA?

Our managed IT services in the USA include complete IT infrastructure management, 24/7 monitoring and support, cybersecurity, cloud services, backup and disaster recovery, help desk support, network management, and proactive maintenance. It's a complete IT department solution with affordable monthly pricing.

What is the response time for IT support in the USA?

GR IT Services responds to P1 critical issues in 5 minutes for managed clients, delivered remotely. We offer 24/7 reliable IT support to businesses across the USA with a guaranteed SLA.

Which areas in the USA does GR IT Services cover?

We provide IT support and managed IT services across all major USA cities including New York, Los Angeles, Chicago, Houston, Phoenix, Philadelphia, San Antonio, San Diego, Dallas, and San Jose. We serve businesses nationwide with complete IT support.

Why is GR IT Services the best IT company in the USA?

GR IT Services combines reliable 24/7 support, a 5-minute P1 response SLA, complete IT solutions, and certified Microsoft CSP and Apple Jamf partner status. We provide IT AMC and managed IT services across the USA with a guaranteed SLA and senior engineers on every engagement.

Firewall rule base audit for US businesses

A rule base only ever gets bigger. Adding a rule fixes the problem in front of you. Taking one away risks breaking something nobody can account for.

The audit asks four questions of every single rule. What does it permit. Who asked for it. Is anything still using it. And would anyone notice if it disappeared. Most businesses can answer the first question for every rule they have, and the remaining three for hardly any of them.

Book a firewall rule audit See what we look for

Firewall rule base audit for US organizations

Four questionsPer rule, and three are usually unanswered
Shadowed rulesRules that can never match anything
Any to anyThe finding that appears in almost every audit
CIS Control 12Network infrastructure management

What we examine

Seven findings that turn up in very nearly every rule base we open.

In version 8.1 of the CIS Critical Security Controls, network infrastructure management sits at Control 12, with secure configuration at Control 4 and network monitoring and defense at Control 13. Your rule base is the single place all three of those meet. It is also, more reliably than any document you hold, a record of what happened to your business rather than what anybody intended.

Permissive rules that were meant to be temporary

An any to any rule, or one permitting an entire subnet to reach another entire subnet across every port, added during a migration or an outage with genuine intent to tighten it the following week. These are the most common serious finding we make. They usually sit near the top of the rule base where they shadow everything underneath, and not one person remembers putting them there.

Shadowed rules that can never match

Any rule sitting beneath a broader rule that matches the same traffic will never once be evaluated. On its own that is not a security problem. What it is, is strong evidence that several people have edited this rule base across several years with nobody ever standing back to look at the whole thing. Shadowed rules also make every change after them harder to reason about safely.

Rules with no traffic against them

Usage data gathered over a representative window shows which rules are earning their place and which are not. Ninety days without a single hit makes a rule a candidate for removal, subject to one obvious question: did that window actually cover the thing the rule exists for. Seasonal traffic, year-end processing and disaster recovery paths are precisely the exceptions that make this a judgment call rather than something a script can decide.

Rules with no owner and no justification

What actually closes out most rules is not whether they are used. It is who asked for the rule and for what reason. Give a rule a change reference, a named requester and a business justification and somebody can review it properly. Give it a comment field reading temp, or a ticket number pointing at a system replaced four years ago, and nobody can. That rule will survive every future review for exactly that reason.

Objects and groups that have drifted from their names

Consider an address group named finance servers that has grown to eleven objects, of which three are not finance servers and one is an entire subnet. That is how a narrow rule quietly turns into a broad one while the rule itself never changes a character. It stays invisible until somebody expands every object in every group, which is not something anybody does casually.

Configuration outside the rule base itself

Management access reachable from anywhere. Administrative accounts shared between people. Logging switched off on the rules that matter most. Firmware several versions behind. High availability that has never once been failed over to prove it works. Secure configuration is Control 4 in the CIS Controls, and an immaculate rule base running on a device anybody can log into is not a control at all.

The gap between what your diagram claims and what the device is doing

Nearly every business holds a network diagram describing the architecture somebody intended, and a rule base describing the one that actually accumulated. Unexpected paths live in the space between those two documents. Reconciling them is often the single most useful thing the audit produces, particularly for whoever has to design the next change.

Why rule bases never shrink

Adding a rule delivers an obvious benefit now. Removing one carries an unclear risk later.

That asymmetry is structural rather than cultural, which is why rule bases grow in one direction in every organization, however good the team looking after them.

A new rule unblocks a project, closes an incident or gets a supplier working. The benefit lands immediately, it can be attributed to whoever delivered it, and somebody is grateful. At the moment it is added it is the right call, and it is almost never the wrong one.
Removing a rule produces nothing anybody can see, alongside a real chance of breaking something nobody wrote down. No engineer has ever been thanked for successfully removing a rule, and everybody remembers the one who removed the wrong one. The incentives point in a single direction.
Evidence is the only thing that reverses this. Usage data proving a rule has matched nothing across a representative window, combined with a documented owner willing to confirm it is finished with, turns removal from a gamble into a decision. Producing that evidence is what the audit is for.
It is also why this work has to finish with a process somebody maintains rather than a one-time cleanup. Without a review cycle, and without a requirement that every new rule carries an owner and, where appropriate, an expiry date, the rule base is back to its old size inside a few years.

Ask us to run a rule base review

How we approach it

Four things that turn an audit report into a rule base that is genuinely smaller.

Generating a findings list from a rule base is mostly mechanical work. Getting rules actually taken out is an entirely different problem, and it turns on evidence and ownership rather than on analysis.

Usage data does the arguing, because an opinion has never removed a rule

Hit counts gathered over a representative window turn a removal from a gamble into a decision. Without them, every proposal amounts to somebody asserting that a rule looks unnecessary, and that assertion never survives its first meeting with the person accountable for whatever might break. Evidence is what makes the conversation short.

We trace ownership before recommending removal

Give a rule a named owner and it can be confirmed or retired inside a single email. A rule with nobody attached needs either archaeology or a controlled disable and observe. Doing that tracing during the audit, rather than handing over a list of unattributed rules and wishing somebody luck, accounts for most of the difference between a report and a result.

We disable before we delete

Where a rule shows no recorded traffic and has no identifiable owner, the safe sequence is disable it, watch for an agreed period, then remove it. That turns the worst possible outcome from an outage into a quick re-enable, and it is what makes the whole exercise something an operations team will sign up to rather than quietly resist.

What we leave behind is a process, not simply a tidier rule base

Three things go in place: every new rule needs a named owner and a business justification, anything temporary carries an expiry date, and a review happens annually with usage data behind it. Leave those out and the rule base returns to its previous size within a few years, at which point the next audit produces this same report for a different audience.

Where this matters most

Six US situations where a rule audit pays for itself quickly.

What prompts this is normally one of three things: a migration, a finding from an audit, or an incident that revealed a path nobody knew was open. All three are sound reasons to act. The first is considerably the cheapest.

An organization migrating to a new firewall platform

No moment is better for shrinking a rule base than migrating it, because every rule has to be looked at regardless. Carry it across unchanged and you have moved a decade of accumulated permissions onto a new platform, squandering the one occasion when removing things is expected rather than resisted.

A regulated firm with a periodic review obligation

A number of frameworks and payment obligations require firewall rules to be reviewed on a stated frequency, and examiners working under GLBA or NYDFS Part 500 will ask to see the evidence. Where you carry an obligation like that, this audit delivers the review and the proof it happened together, with a written decision recorded against every rule rather than a signature confirming somebody once looked.

A business in scope for payment card requirements

The current version in the standards council document library is PCI DSS 4.0.1, and network controls have sat at the heart of it from the beginning. Where card data is in scope for you, the segmentation your rule base implements is the control deciding how much of the estate falls in scope. That makes the accuracy of those rules a commercial matter as much as a security one.

An operator with converged operational and corporate networks

When production systems sit behind rules written across many years, the distance between intended segmentation and actual segmentation stops being purely a security question and becomes a safety one too. For this kind of environment, reconciling the documented design against the live rule base is usually the most valuable single thing we hand back.

A group that has grown by acquisition

Every acquisition arrives carrying a rule base written by a different team working to different conventions, and integrating it usually means adding permissive rules to get things moving quickly. Auditing across the whole group produces one consistent picture, and it surfaces the temporary integration paths that have now been in place for several years.

An organization that has just found an unexpected path

This is what usually prompts the call. Somebody finds that one system can reach another it has no business reaching, and the immediate question becomes what else looks like that. A full rule audit is the only way to answer it, and the answer is nearly always that several more exist, of which one or two genuinely matter.

Three positions

How US organizations manage their firewall rule bases.

The middle column is simply normal. Changes follow a proper process, every rule was justified on the day it went in, and nothing has ever come out again.

New rules require justification

Audited and maintainedYes

Changes controlled, nothing removedYes

Unmanaged rule baseNo

Rules have an identified owner

Audited and maintainedYes

Changes controlled, nothing removedFor recent ones

Unmanaged rule baseNo

Unused rules identified

Audited and maintainedYes

Changes controlled, nothing removedNo

Unmanaged rule baseNo

Shadowed rules removed

Audited and maintainedYes

Changes controlled, nothing removedNo

Unmanaged rule baseNo

Object groups match their names

Audited and maintainedYes

Changes controlled, nothing removedDrifted

Unmanaged rule baseUnknown

Any-to-any rules known and scoped

Audited and maintainedYes

Changes controlled, nothing removedPresent, unnoticed

Unmanaged rule basePresent

Management access restricted

Audited and maintainedYes

Changes controlled, nothing removedUsually

Unmanaged rule baseNo

Documented design matches reality

Audited and maintainedYes

Changes controlled, nothing removedNo

Unmanaged rule baseNo design

Temporary rules expire

Audited and maintainedYes

Changes controlled, nothing removedNo

Unmanaged rule baseNo

Rule count trend

Audited and maintainedStable

Changes controlled, nothing removedRising

Unmanaged rule baseRising

Feature	Audited and maintained	Changes controlled, nothing removed	Unmanaged rule base
New rules require justification	Yes	Yes	No
Rules have an identified owner	Yes	For recent ones	No
Unused rules identified	Yes	No	No
Shadowed rules removed	Yes	No	No
Object groups match their names	Yes	Drifted	Unknown
Any-to-any rules known and scoped	Yes	Present, unnoticed	Present
Management access restricted	Yes	Usually	No
Documented design matches reality	Yes	No	No design
Temporary rules expire	Yes	No	No
Rule count trend	Stable	Rising	Rising

The finding categories

Nine categories, and what we do with each.

Classifying findings this way is what makes the output a list of decisions rather than an undifferentiated report somebody files. Treat the recommendation column as an opening position, adjusted in conversation with whoever owns the systems sitting behind each rule.

Finding

Any to any, or any service permitted

Why it matters: Allows far more than anybody meant it to, and usually shadows whatever sits below
Default recommendation: Scope to the actual requirement, urgently

Finding

Overly broad source or destination

Why it matters: A subnet where a host was needed
Default recommendation: Narrow to the specific systems, with the owner confirming

Finding

Shadowed rule

Why it matters: Will never match anything, while making the rest of the base harder to reason about
Default recommendation: Remove, after confirming the shadowing rule is correct

Finding

No traffic over the review period

Why it matters: Likely obsolete, subject to seasonal exceptions
Default recommendation: Disable, observe, then remove

Finding

No owner or justification

Why it matters: Cannot be reviewed, so survives indefinitely
Default recommendation: Track down an owner, or put it on the removal list

Finding

Object or group drift

Why it matters: A narrow rule that has silently become broad
Default recommendation: Rebuild the group to match its name and purpose

Finding

Logging disabled

Why it matters: No record of what the rule permitted
Default recommendation: Enable, unless there is a documented volume reason

Finding

Management access too broad

Why it matters: Secure configuration failure, independent of the rules
Default recommendation: Restrict to a management network, with named accounts

Finding

Divergence from the documented design

Why it matters: Unexpected paths that nobody designing a change would predict
Default recommendation: Reconcile, and correct whichever is wrong

Finding	Why it matters	Default recommendation
Any to any, or any service permitted	Allows far more than anybody meant it to, and usually shadows whatever sits below	Scope to the actual requirement, urgently
Overly broad source or destination	A subnet where a host was needed	Narrow to the specific systems, with the owner confirming
Shadowed rule	Will never match anything, while making the rest of the base harder to reason about	Remove, after confirming the shadowing rule is correct
No traffic over the review period	Likely obsolete, subject to seasonal exceptions	Disable, observe, then remove
No owner or justification	Cannot be reviewed, so survives indefinitely	Track down an owner, or put it on the removal list
Object or group drift	A narrow rule that has silently become broad	Rebuild the group to match its name and purpose
Logging disabled	No record of what the rule permitted	Enable, unless there is a documented volume reason
Management access too broad	Secure configuration failure, independent of the rules	Restrict to a management network, with named accounts
Divergence from the documented design	Unexpected paths that nobody designing a change would predict	Reconcile, and correct whichever is wrong

How an engagement runs

Five steps, and disabling before deleting is not negotiable.

The audit itself runs two to four weeks, depending on how many devices are involved and how large the rule bases are. It is delivered remotely from configuration exports and usage data, after which remediation happens in a window that fits your own change process rather than ours.

1
Collect configuration and usage data
We need configuration exports from every device in scope, branch and cloud firewalls included, along with rule usage data covering a representative period, with ninety days as a sensible floor. Read-only access is normally all that is required, and where a central management platform exists the collection goes considerably faster.
2
Analyze the rule base against the finding categories
Seven categories: overly permissive rules, shadowed rules, rules carrying no traffic, rules with no owner or justification attached, drift in objects and groups, gaps in logging, and management access. Everything found is categorized, which is what makes the output a list of decisions rather than an undifferentiated catalog of everything that could theoretically be improved.
3
Trace ownership and reconcile with the design
We go through change records, chase ticket references and talk to the people most likely to remember, so that as many rules as possible reach the review with an owner already attached to them. Running alongside that, the live rule base gets compared against the documented network design, since the space between those two is where the surprising paths turn out to live.
4
Agree the actions, then disable before deleting
Permissive rules get scoped down urgently, shadowed ones get removed outright, and anything with no traffic and no owner goes through disable and observe. That last step is what turns the worst possible outcome from an outage into a quick re-enable, and it is the reason an operations team will agree to move at pace rather than dragging it out over two quarters.
5
Leave a process that keeps the base clean
Three requirements go in: a named owner and a business justification on every new rule, an expiry date on anything anybody describes as temporary, and an annual review driven by usage data. Without them the base grows back to its former size, and the next audit produces findings identical to these.

Straight answers

What organizations ask about firewall rule audits.

Two things: configuration exports from the devices in scope, and rule usage data spanning a representative period, ninety days being a sensible floor. Read-only access normally covers it, and the entire audit runs remotely. A network diagram and whatever change records exist help a great deal more than people expect, because that is where rule ownership comes from, and ownership is what decides whether a rule can ever be retired.

The audit itself changes nothing, since it works entirely from exports and usage data. Remediation obviously does involve changes, and those pass through your change process at whatever pace you set. Plenty of organizations take the audit on its own first, decide what they actually want to act on, and schedule the changes as a separate piece of work afterwards.

It is a rule sitting underneath a broader one that matches the same traffic, meaning it can never be evaluated at all. By itself that is not a security exposure. What it is, is compelling evidence that several people have edited this rule base across several years without anybody once reviewing it end to end. Shadowed rules also make every change that comes afterwards harder to reason about correctly.

Usually, though never automatically. The question to ask first is whether your observation window actually covered what the rule exists for. Year-end processing, seasonal operations, disaster recovery paths and annual audit access all produce rules that legitimately sit idle for months at a stretch. That is exactly why we disable and observe rather than deleting on the strength of usage data alone.

That varies enormously depending on how old the rule base is and how many different teams have been through it. What stays consistent is that the proportion always exceeds what the business expected. And the reason those rules survived is almost never that somebody assessed them and chose to keep them. It is that nobody ever held enough evidence to justify taking them out.

It means a group that has stopped matching its own name and purpose. Picture an address group called finance servers holding eleven objects, three of which are nothing of the sort and one of which is an entire subnet. The rule referencing that group has not been touched in years, while what it permits has changed substantially. None of it is visible unless somebody expands every object in every group.

We do, because an immaculate rule base running on a badly configured device is not a control. The scope of management access, how administrative accounts are handled, the logging state on each rule, how current the firmware is and whether the high availability arrangement works all sit under secure configuration, which is Control 4 in version 8.1 of the CIS Critical Security Controls.

The two answer different questions and sit together well. A penetration test tells you what an attacker can reach from wherever they currently stand. A rule audit tells you what the configuration permits, including the paths no test would ever find, because they only become usable from a position the tester never reached. Each one finds things the other cannot.

Your obligations decide that. A number of frameworks and payment requirements call for periodic review of network controls, and wherever one applies to you we check the required frequency against the wording of that obligation instead of assuming whichever interval is common. Where no specific requirement exists, an annual review backed by usage data is a sound baseline for most businesses.

It should, and cloud is very often where the newest permissive rules are hiding. Network security groups and cloud firewall policies accumulate exactly the way an on-premises rule base does, usually faster, because far more people hold the ability to change them. Bringing them into scope at the start stops you ending up with a spotless on-premises picture sitting next to a cloud estate nobody examined.

Almost always a permissive rule sitting near the top of the base, added in the middle of a migration or an incident with every intention of tightening it the following week, permitting far more than anybody now believes and shadowing a number of carefully written rules underneath it. It appears in the large majority of rule bases we review and is very seldom known about. Outbound deserves its own mention here. Permissive outbound rules are extremely common, almost never reviewed, and they are what lets command and control traffic and data movement proceed without meeting any resistance at all.

Three changes, of which the first does most of the work. Insist on a named owner and a business justification for every new rule. Insist on an expiry date for anything anybody calls temporary. And put an annual review using usage data into the calendar. Skip the first and ownership becomes unrecoverable inside two years, at which point removing anything is impossible all over again. Engagements are scoped on device count and rule base size, because the analysis effort tracks the number of rules rather than the size of the business, and remediation gets scoped separately once we all know what the findings are.

Before the audit

Fifteen things that make the audit faster and better.

Group one covers access. Group two covers context. Group three covers what happens once we leave, and that is what decides whether the rule base stays clean or drifts straight back.

Access

Can we get a configuration export?
Read-only access is usually sufficient.
Is rule usage data available?
Hit counts over a representative period.
How long is the usage window?
Ninety days is a reasonable minimum.
Are all devices in scope?
Including branch and cloud firewalls.
Is there a central management platform?
It makes the export far easier.

Context

Is there a network diagram?
Even an out of date one helps.
Is there a change record for rules?
That is where owners come from.
Are there seasonal or annual paths?
They must not be removed on usage alone.
Any regulatory obligation in play?
PCI DSS or an examiner may set a review frequency.
Which segments matter most?
Prioritize the ones protecting real value.

Afterwards

Who approves a removal?
Decide before the list arrives.
Is there a change window?
Removals happen in batches.
Do new rules require an owner?
The single most effective change.
Do temporary rules carry an expiry?
Otherwise they are permanent.
When is the next review?
Annually, or the base regrows.

The pages around this one.

Penetration testing

Finding out what can genuinely be reached, next to what the configuration allows on paper.

Wireless security audit

The other half of the network edge: what is broadcasting, how it authenticates, and what it reaches.

Cybersecurity audit and compliance

The wider audit practice, and how to tell which kind of engagement your situation actually calls for.

Next step

Count the rules on your primary firewall. Then find out how many came out during the last twelve months.

Where that second number is zero, what you have is a rule base recording your history rather than expressing your intent. That is entirely normal and entirely fixable, and a first audit reliably turns up one permissive rule that changes the tone of the conversation completely.

Book a firewall rule audit See the audit practice

Related Services

Explore more solutions that work great with this service

A rule base only ever gets bigger. Adding a rule fixes the problem in front of you. Taking one away risks breaking something nobody can account for.

Seven findings that turn up in very nearly every rule base we open.

Feature

Audited and maintained

Changes controlled, nothing removed

Unmanaged rule base

New rules require justification

Yes

Rules have an identified owner

Yes

For recent ones

Unused rules identified

Yes

Shadowed rules removed

Yes

Object groups match their names

Yes

Drifted

Unknown

Any-to-any rules known and scoped

Yes

Present, unnoticed

Present

Management access restricted

Yes

Usually

Documented design matches reality

Yes

No design

Temporary rules expire

Yes

Rule count trend

Stable

Rising

Finding

Why it matters

Default recommendation

Any to any, or any service permitted

Allows far more than anybody meant it to, and usually shadows whatever sits below

Scope to the actual requirement, urgently

Overly broad source or destination

A subnet where a host was needed

Narrow to the specific systems, with the owner confirming

Shadowed rule

Will never match anything, while making the rest of the base harder to reason about

Remove, after confirming the shadowing rule is correct

No traffic over the review period

Likely obsolete, subject to seasonal exceptions

Disable, observe, then remove

No owner or justification

Cannot be reviewed, so survives indefinitely

Track down an owner, or put it on the removal list

Object or group drift

A narrow rule that has silently become broad

Rebuild the group to match its name and purpose

Logging disabled

No record of what the rule permitted

Enable, unless there is a documented volume reason

Management access too broad

Secure configuration failure, independent of the rules

Restrict to a management network, with named accounts

Divergence from the documented design

Unexpected paths that nobody designing a change would predict

Reconcile, and correct whichever is wrong

A rule base only ever gets bigger. Adding a rule fixes the problem in front of you. Taking one away risks breaking something nobody can account for.

Seven findings that turn up in very nearly every rule base we open.

Permissive rules that were meant to be temporary

Shadowed rules that can never match

Rules with no traffic against them

Rules with no owner and no justification

Objects and groups that have drifted from their names

Configuration outside the rule base itself

The gap between what your diagram claims and what the device is doing

Adding a rule delivers an obvious benefit now. Removing one carries an unclear risk later.

Four things that turn an audit report into a rule base that is genuinely smaller.

Usage data does the arguing, because an opinion has never removed a rule

We trace ownership before recommending removal

We disable before we delete

What we leave behind is a process, not simply a tidier rule base

Six US situations where a rule audit pays for itself quickly.

An organization migrating to a new firewall platform

A regulated firm with a periodic review obligation

A business in scope for payment card requirements

An operator with converged operational and corporate networks

A group that has grown by acquisition

An organization that has just found an unexpected path

How US organizations manage their firewall rule bases.

Nine categories, and what we do with each.

Any to any, or any service permitted

Overly broad source or destination

Shadowed rule

No traffic over the review period

No owner or justification

Object or group drift

Logging disabled

Management access too broad

Divergence from the documented design

Five steps, and disabling before deleting is not negotiable.

Collect configuration and usage data

Analyze the rule base against the finding categories

Trace ownership and reconcile with the design

Agree the actions, then disable before deleting

Leave a process that keeps the base clean

What organizations ask about firewall rule audits.

What do you actually need from us?

Can you do this without touching our firewalls?

What is a shadowed rule?

Is a rule with no traffic safe to remove?

How many rules do you usually recommend removing?

What is object group drift?

Do you look at anything other than the rules?

How does this relate to a penetration test?

Is there a required review frequency?

Does this cover cloud firewalls?

What is the most common serious finding?

How do we stop the rule base regrowing, and what does an engagement cost?

Fifteen things that make the audit faster and better.

Access

Context

Afterwards

The pages around this one.

Penetration testing

Wireless security audit

Cybersecurity audit and compliance

Count the rules on your primary firewall. Then find out how many came out during the last twelve months.

Related Services

Wireless Security Audit

Penetration Testing

Vulnerability Assessment

Zero Trust Architecture Assessment

Managed IT Services

A rule base only ever gets bigger. Adding a rule fixes the problem in front of you. Taking one away risks breaking something nobody can account for.

Seven findings that turn up in very nearly every rule base we open.

Permissive rules that were meant to be temporary

Shadowed rules that can never match

Rules with no traffic against them

Rules with no owner and no justification

Objects and groups that have drifted from their names

Configuration outside the rule base itself

The gap between what your diagram claims and what the device is doing

Adding a rule delivers an obvious benefit now. Removing one carries an unclear risk later.

Four things that turn an audit report into a rule base that is genuinely smaller.

Usage data does the arguing, because an opinion has never removed a rule

We trace ownership before recommending removal