Hi Santosh, WS Security is always interesting to solve. In many cases, the teams do not know all of the answers because a component in the application framework is taking care of the security. In essence, it is hidden from the team.
Check out this link for guidance on the behavior of the WS Security DPH and the configurations. WS - Security Request Data Protocol - DevTest Solutions - 9.5 - CA Technologies Documentation
On the request side, your DPH will tear down the WS Security info the way the server does. This means the order in which WS Security information is processed will be the same order the server expects. On the response side, the DPH must order the WS Security info in reverse just as the server does.
For example, assume that the signature verification is inside the encrypted request. You need to decrypt the request first and then apply the signature verification. If the verification is outside the encrypted request, add signature verification first, then decrypt. On the response side, you might need to apply the signature token first and then encrypt the payload.
You may need help from both the application and security team to get the request / response security information into the correct order.
If you happen to post WSS policy information, please remove or mask any customer-specific or server data just to be on the safe side.