As I'm sure you are learning, PCI compliance is a complicated business. The payment processor (I discuss eWay below) and your own operations play the biggest role in PCI compliance. Some of the issues on the organization's end are:
- your own server's security protocols (including, but not limited to, SSL)
- how the payment information is transferred to the payment processor
- in-office protocols for access to data both on- and off-line
A great starting point is http://gitbook.civicrm.org/initial-set-up/security.html
One component is whether or not your site is utilizing SSL. The CiviCRM wiki on Security and PCI Compliance has some excellent points about SSL.
CiviCRM itself does not store credit card information in the database, but if you are collecting credit card info on your Civi forms and then sending it to the payment processor, the credit card info will be on your server temporarily by default (see Lobo's comment here from 2011) so your server will need to be PCI compliant. (Eileen mentions options like direct post and transparent redirect in this CiviCon talk for certain payment processors, but that takes some semblance of custom work: Adventures in Payment Processing).
For eWay specifically, their website says they are tier one PCI DSS compliant. If you are sending people to an external site for eWay to process on their site (I don't know if that's an option for eWay), then a lot of the responsibility for PCI compliance gets off-loaded as well. If you are collecting credit card info on your own Civi forms and then sending the info to eWay, they have a page about your organization's responsibilities in PCI compliance.
A great explanation of PCI compliance and things an organization should consider relating to PCI compliance is available from this CiviCon Denver 2015 talk: CiviCon Denver Data Security and Payment.
