It can NOT be tested.

There are lot's of websites talking about the theoretical aspects of software testing. However, far little websites talk about all practical aspects of projects and companies. 

So in theory a company can have a test policy, and/or a MasterTestPlan (MTP). It can even go as far that they have the work processes arranged in a manner that if they would do a TTMi or similar check-up they would score a level-5 optimized! wow great.

It doesn't say anything about what a software tester will encounter on the work floor during his working days. Most of the websites that write about software testing write in a way as of it seems "everything can be tested".
Whilst after almost 20 years of software testing you've learned, that is not entirely accurate.

To break it down there are nuances in this:
1) It can be tested, but not by the/this software tester.
2) It can't be tested in this environment (proof is in the pudding, production)

Scenario 1:
Can be caused by lack of application knowledge, lack of test (methods/techniques/...) experience.
Whatever the case, the tester needs help from another person in the organisation or even the testers needs confirmation (for verification) from another person that the outcome is correct.

Scenario 2: 
For several kinds of reasons, sometimes testing is very hard or even impossible. 
Thinking of a expensive mission to Mars makes this scenario easier to imagine.
(A little helicopter on Mars once functioned beyond expectation by the way)

Fact is that there are things that can be controlled and things that can't be controlled. An example of my own experiences is:

Although there were rules about putting new programming code into production, an employee (developer) himself determined what he did.

This is just an example, but my point is... : 
Try to find a website that tells you what to do in such cases! Show me the website were that is explained?

Are such moments unique? of course not, they happen all the time. Constantly.

In theory everything could be systematically and structured, but that is almost never the case. For some reason, some client finds a bug and it appears that the bug has big impact and thus high priority all of a sudden.
If we think back of the scenario's 1 and 2, of course it is more a scenario 2 like problem.

Can you honestly say as a software tester that of a new version of the software, everything that is new in that version has actually been (re)viewed by yourself?
No, but that is many cases in stark contrast with the expectations of our role.

Reality is:
(In scenario 0 we can test.)
​In scenario 1 we can assist.
In scenario 2 we can only sit and wait.