Unless absolutely necessary, do not give your pentester access to your production systems. Instead, create a dummy system with the same configuration but without any sensitive data stored in databases, etc. If you let the pentester work on the production systems, you will have to trust them. If it is absolutely necessary to allow an untrustworthy pentester to operate on production systems, at least make an off-site backup so any changes to the server can be compared to the backup.

This may not be possible if the entire network needs to be tested, or if a test system that behaves identically to the production system cannot be set up. In that case, you will need to trust them.

Generally however, a qualified pentester will be trustworthy. It is not worth it to them to compromise your computer, yet ruin their reputation in an industry where it's so hard to gain it back. Both you and the pentester will sign a contract specifying what they are allowed to do, what attacks are in-scope, etc. This will allow you to prove malpractice in the case that they step out of bounds (for example, if they stress test your production server against your wishes and end up effectively denying service to your clients).

Unless absolutely necessary, do not give your pentester access to your production systems. Instead, create a dummy system with the same configuration but without any sensitive data stored in databases, etc. If you let the pentester work on the production systems, you will have to trust them. If it is absolutely necessary to allow an untrustworthy pentester to operate on production systems, at least make an off-site backup so any changes to the server can be compared to the backup.

This may not be possible if the entire network needs to be tested, or if a test system that behaves identically to the production system cannot be set up. In that case, you will need to trust them.

Generally however, a qualified pentester will be trustworthy. It is not worth it to them to compromise your computer and ruin their reputation in an industry where it's so hard to gain it back. Both you and the pentester will sign a contract specifying what they are allowed to do, what attacks are in-scope, etc. This will allow you to prove malpractice in the case that they step out of bounds (for example, if they stress test your production server against your wishes and end up effectively denying service).

Unless absolutely necessary, do not give your pentester access to your production systems. Instead, create a dummy system with the same configuration but without any sensitive data stored in databases, etc. If you let the pentester work on the production systems, you will have to trust them. If it is absolutely necessary to allow an untrustworthy pentester to operate on production systems, at least make an off-site backup so any changes to the server can be compared to the backup.

Generally however, a qualified pentester will be trustworthy. It is not worth it to them to compromise your computer, yet ruin their reputation in an industry where it's so hard to gain it back.

Unless absolutely necessary, do not give your pentester access to your production systems. Instead, create a dummy system with the same configuration but without any sensitive data stored in databases, etc. If you let the pentester work on the production systems, you will have to trust them. If it is absolutely necessary to allow an untrustworthy pentester to operate on production systems, at least make an off-site backup so any changes to the server can be compared to the backup.

This may not be possible if the entire network needs to be tested, or if a test system that behaves identically to the production system cannot be set up. In that case, you will need to trust them.

Generally however, a qualified pentester will be trustworthy. It is not worth it to them to compromise your computer, yet ruin their reputation in an industry where it's so hard to gain it back. Both you and the pentester will sign a contract specifying what they are allowed to do, what attacks are in-scope, etc. This will allow you to prove malpractice in the case that they step out of bounds (for example, if they stress test your production server against your wishes and end up effectively denying service to your clients).